Bug 53781

Summary: Web Inspector: check-inspector-strings doesn't process Unicode literals in .js sources
Product: WebKit Reporter: Mikhail Naganov <mnaganov>
Component: Web Inspector (Deprecated)Assignee: Mikhail Naganov <mnaganov>
Status: RESOLVED FIXED    
Severity: Normal CC: apavlov, bweinstein, joepeck, keishi, loislo, pfeldman, pmuellr, rik, timothy, yurys
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Attachments:
Description Flags
patch
mnaganov: commit-queue-
renamed function pfeldman: review+, mnaganov: commit-queue-

Description Mikhail Naganov 2011-02-04 09:48:15 PST
In localizedStrings.js all characters are represented as themselves, while in .js sources Unicode chars can be represented as \u escape sequences. check-inspector-strings doesn't convert \u sequences into corresponding characters, and thus doesn't match such strings correctly.
Comment 1 Mikhail Naganov 2011-02-04 09:50:27 PST
Created attachment 81237 [details]
patch
Comment 2 Joseph Pecoraro 2011-02-04 09:54:47 PST
Comment on attachment 81237 [details]
patch

I think you can give "convert_string" a better name. The comment inside it is more descriptive,
how about, "decode_unicode_escapes", "decode_unicode", etc? Just a thought.

With this improvement are there any changes to the localizedStrings.js file?
Comment 3 Mikhail Naganov 2011-02-04 10:07:49 PST
(In reply to comment #2)
> (From update of attachment 81237 [details])
> I think you can give "convert_string" a better name. The comment inside it is more descriptive,
> how about, "decode_unicode_escapes", "decode_unicode", etc? Just a thought.
>

decode_unicode_escapes is a good one. It eliminates the need for the comment.
 
> With this improvement are there any changes to the localizedStrings.js file?

No. This code allows to match, e.g. ellipsis character from localizedStrings.js to its \u2026 counterpart from .js source.

BTW, why localizedStrings.js uses UTF-16 -- this makes resolving conflicts painful. Can we convert it to UTF-8 or do you have any restrictions from your l10n process?
Comment 4 Mikhail Naganov 2011-02-04 10:09:16 PST
Created attachment 81240 [details]
renamed function
Comment 5 Mikhail Naganov 2011-02-04 10:28:59 PST
Manually committed http://trac.webkit.org/changeset/77641
Comment 6 Joseph Pecoraro 2011-02-04 10:40:41 PST
(In reply to comment #3)
> BTW, why localizedStrings.js uses UTF-16 -- this makes resolving
> conflicts painful. Can we convert it to UTF-8 or do you have any
> restrictions from your l10n process?

Pavel has had the same question.  Googling, I see a novel idea:
http://fi.am/entry/keeping-your-localizablestrings-in-utf-8/

Let me ask internally now! I personally have no idea, other then
comments on the web and vague comments in the documentation
that say UTF-16 is preferred.