RESOLVED FIXED53781
Web Inspector: check-inspector-strings doesn't process Unicode literals in .js sources
https://bugs.webkit.org/show_bug.cgi?id=53781
Summary Web Inspector: check-inspector-strings doesn't process Unicode literals in .j...
Mikhail Naganov
Reported 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.
Attachments
patch (1.57 KB, patch)
2011-02-04 09:50 PST, Mikhail Naganov
mnaganov: commit-queue-
renamed function (1.53 KB, patch)
2011-02-04 10:09 PST, Mikhail Naganov
pfeldman: review+
mnaganov: commit-queue-
Mikhail Naganov
Comment 1 2011-02-04 09:50:27 PST
Joseph Pecoraro
Comment 2 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?
Mikhail Naganov
Comment 3 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?
Mikhail Naganov
Comment 4 2011-02-04 10:09:16 PST
Created attachment 81240 [details] renamed function
Mikhail Naganov
Comment 5 2011-02-04 10:28:59 PST
Joseph Pecoraro
Comment 6 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.
Note You need to log in before you can comment on or make changes to this bug.