Bug 27288 – Inspector: Missing UIString and other localizedString.js fixes

• Component: Web Inspector (Deprecated)
• Status: RESOLVED FIXED

[Joseph Pecoraro]

localizedStrings.js was missing "This storage is empty." and had two improperly sorted strings.

[Joseph Pecoraro]

Created attachment 32763 [details]
Localized String Fixes

Added the missing string and correctly sorted two other keys ("COOKIES" and "Time").

[Joseph Pecoraro]

I just realized COOKIES is not yet committed, its something that I've been working on.  Should I submit a new patch that doesn't have COOKIES in it but fixes the other issues?  Or should I leave in COOKIES which will fall into place when that bug gets resolved:
https://bugs.webkit.org/show_bug.cgi?id=27202

[Joseph Pecoraro]

Last Comment, something I forgot to mention: I ran a grep to search for all the currently used UIString() calls and verified that they all exist in localizedStrings.js.  This means that all calls to UIString(), in WebCore/inspector/front-end/*.js are properly in localizedString.js.  I didn't look for strings that didn't have UIString but might need it, or in any other files.  Are there other places to hunt for mistake?

Cheers.

[Eric Seidel (no email)]

Hard to review this type of patch w/o being able to see it.

[Joseph Pecoraro]

Created attachment 32819 [details]
plain/text version of the new file

Hmm, when I do a `file WebCore/English.lproj/localizedStrings.js` I get no mime/type.  Do you think if I change the mime type by deleting and recreating the file it would be okay. Then the patches would apply as though it was text.  Or is this unusual format required for English.lproj to recognize it?

[Jan Alonzo]

(In reply to comment #5)
> Created an attachment (id=32819) [details]
> plain/text version of the new file
> 
> Hmm, when I do a `file WebCore/English.lproj/localizedStrings.js` I get no
> mime/type.  Do you think if I change the mime type by deleting and recreating
> the file it would be okay. Then the patches would apply as though it was text. 
> Or is this unusual format required for English.lproj to recognize it?

Are you able to create a plain/text version of the diff? You can do this using iconv and just do a manual diff of the two files.

[Joseph Pecoraro]

Okay a few things.  First the issue I think is causing the assumed binary.

  shell> file localizedStrings.js
  localizedStrings.js: 

Then iconv didn't actually work =/.

  shell> iconv -t UTF8 localizedStrings.js 
  iconv: localizedStrings.js:1:0: cannot convert

`cat`, `cp`, or even opening the file in an editor and saving it didn't change that information for me.  What I actually had to do was open it in an editor, copy the text over to a new document and save a new file.  I did this for both the new and old, attahed is the manual diff.

[Joseph Pecoraro]

Created attachment 33024 [details]
Manual Diff

NOTES:

- I thought "Time" was incorrectly sorted, but that was just because I had just added two strings next to "Time" in apparently the wrong spot.
- This still has the new strings for "Cookies" which have yet to be added to the inspector.  https://bugs.webkit.org/show_bug.cgi?id=27202 So maybe you want me to just revert and then resubmit a patch with the 1 line fix.

[Joseph Pecoraro]

Created attachment 33025 [details]
Manual Diff

Wow... that was frustrating.  Its clearly plain/text but that mime type wasn't working.  Take 2.

[Patrick Mueller]

Anyone know why English.lproj/localizedStrings.js is maintained as UTF16 encoded?  I think I noticed Trac does the right thing with the file, but diffs and other tools don't.  The actual content of the file doesn't require it to be UTF16, even it has (or had or could have) non-ascii chars in it, because those would be in the JS strings and so could be escaped.

My only guess is some tool during a translation or build step is assuming UTF16.

In that case, perhaps we can keep the "development" version of the file as a plain old ascii file, using unicode escapes as needed.  For whatever tool needs the UTF16 version, we can write a filter invoked during build that will read the ascii version and convert to UTF16.

[Adam Barth]

Committing to http://svn.webkit.org/repository/webkit/trunk ...
	M	WebCore/ChangeLog
	M	WebCore/English.lproj/localizedStrings.js
Committed r46332
	M	WebCore/ChangeLog
	M	WebCore/English.lproj/localizedStrings.js
r46332 = 7995bbbd08706997f37891031a3b2ea353b5bcaf (trunk)
No changes between current HEAD and refs/remotes/trunk
Resetting to the latest refs/remotes/trunk
http://trac.webkit.org/changeset/46332