Closed
Bug 224748
Opened 21 years ago
Closed 21 years ago
'hard-coded' character encoding names should be canonical
Categories
(Core :: Internationalization, defect)
Core
Internationalization
Tracking
()
RESOLVED
FIXED
People
(Reporter: jshin1987, Assigned: jshin1987)
References
Details
(Keywords: intl, l12y)
Attachments
(2 files)
3.50 KB,
patch
|
smontagu
:
review+
blizzard
:
superreview+
|
Details | Diff | Splinter Review |
3.83 KB,
patch
|
Details | Diff | Splinter Review |
In some parts of Mozilla, it's assumed that all 'internal' character encoding names(as opposed to coming from external sources) are canonical. However, this assumption doesn't hold because some hard-coded encoding names are not canonical. For instance, the following has a bunch of non-canonical names: (see bug 222346 comment #17) http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/locale/en-US/navigator.properties#25 Another place is 'Unix ps font-encoding mapping properties'. However, in that case, the aforementioned assumption is not made and charset alias resolution is invoked. When fixing these, authors of lang. packs should be notified so that they can update lang packs accordingly. This bug has little to do with the localizability but there's no keyword for the localization so I'm using l12y for the now.
Assignee | ||
Comment 1•21 years ago
|
||
Beofre asking for r/sr, I'll be running a build with this patch for a while to see if there's any side-effect. I can't think of any, but there might be a reason I'm not aware of for using all lower-cases for intl.charsetmenu.more[1-5].
Assignee | ||
Comment 2•21 years ago
|
||
same as attachment 134496 [details] [diff] [review] for firebird
Assignee | ||
Updated•21 years ago
|
Status: NEW → ASSIGNED
Summary: 'hard-coded' character encoding names should be canonical → 'hard-coded' character encoding names should be canonical
Assignee | ||
Comment 3•21 years ago
|
||
Comment on attachment 134996 [details] [diff] [review] patch asking for r/sr. What I was a bit unsure was how various properties assosicated with charset names would be affected by the change. It turned out that they're always converted to lowercase before properties are searched for with them as 'hashkeys'. So, there's no problem. smontagu, while you're at this, it'd be nice if you can review the patch for bug 222346 as well.
Attachment #134996 -
Flags: superreview?(blizzard)
Attachment #134996 -
Flags: review?(smontagu)
Updated•21 years ago
|
Attachment #134996 -
Flags: superreview?(blizzard) → superreview+
Comment 4•21 years ago
|
||
I've doublechecked that the canonical names in the patch are all correct per charsetalias.properties, but there is one thing that I don't get here: if the charset names are always converted to lowercase before use, why do we care what the case is in the property file? In other words, what problem is this solving?
Comment 5•21 years ago
|
||
Comment on attachment 134996 [details] [diff] [review] patch OK, I read bug 203838 comment 14, which is jshin's response to my comment 4. r=smontagu.
Attachment #134996 -
Flags: review?(smontagu) → review+
Assignee | ||
Comment 6•21 years ago
|
||
Thanks for rewiew. Fix checked into the trunk. bryner, can you check in firebird patch? Thanks.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Comment 7•21 years ago
|
||
I don't want to step into bryner' shoes, but the Firebird partition is now open. a=me, go ahead! :-)
Comment 8•21 years ago
|
||
The enthusiasm may have lost me. I have few comments, but that should not prevent you to check that in (it's better to stay in sync) and it could be dealt in other bugs. 1) I am not sure if we (FB) are using our own character encoding names. jshin (smontagu or anyone interested), we have to speak together to know what is the best to remove the communicator dependencies: (see http://lxr.mozilla.org/mozilla/source/browser/app/profile/all.js#461 ) 2) If localizers just have to copy the changes in their language pack, I was naively wondering if we could package these encoding names into chrome://browser/content, instead of chrome://browser/.../locale. Do we provide all the encoding names that we support or is it sth that the localizer can tweak ? That's a common trick to put in .../content stuff we don't want 3rd party to modify (ex: the about logo, the autoscroll icon, etc...)
Assignee | ||
Comment 9•21 years ago
|
||
sorry for the delayed response. The fix got in for firebird.
> is it sth that the localizer can tweak
The list of supported encodings is fixed, but which one to put in the charset
selection menu (and more1...5 menu) and which one not to depends on the localizer.
As for point #1, I just found that you had gotten rid of that dependency.
Comment 10•18 years ago
|
||
*** Bug 167109 has been marked as a duplicate of this bug. ***
You need to log in
before you can comment on or make changes to this bug.
Description
•