[Webkit-unassigned] [Bug 28685] New: make localizedString.js diff- and commit- friendly

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=28685

           Summary: make localizedString.js diff- and commit- friendly
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: PC
        OS/Version: Mac OS X 10.5
            Status: UNCONFIRMED
          Severity: Normal
          Priority: P2
         Component: Web Inspector
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: pmuellr at yahoo.com


The file WebCore/English.lproj/localizedStrings.js is currently a UTF16 LE
encoded file.  Though if you look at the file, it's just plain old JavaScript
code.  There are some fancy quotes in some strings - search for the string
"table" to find them.  And perhaps other non-ascii characters.

As this is a UTF16 file, various tools along the way to landing patches get
confused.  Diff tools give up, for instance, as treat the file as binary.  Trac
actually seems to display the diffs for changesets, but that's after the fact. 
As it is now, it's difficult for someone reviewing a patch to see what the
diffs are, and presumably very hard for someone having to merge multiple
changes in.

I'd like to have a discussion of being able to treat this file somehow as an
8-byte encoded file.  Either using UTF8 encoding for the file, so folks can
continue to use "fancy" characters wherever they want, or as an ASCII file
where we use Unicode escaping within the JavaScript string files (eq, \u0001).

One thing that's not clear to me is what the requirements on the use of this
file are, by downstream consumers.  Presumably folks like Apple use this file
as input to various translation processes.

I think the worse-case scenario would be having a build step which took an
8-bit encoded version of the file and output a 16-bit version for whatever tool
needs it.  

We should also do an experiment to verify that the parts of the toolchain we
use that aren't friendly with the UTF16 file, are in fact friendly with a UTF8
file, if we decide that UTF8 is the format to use.  Wouldn't be much good to
convert the file to UTF8 only to find we haven't fixed the real problem.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.