Closed Bug 224748 Opened 21 years ago Closed 21 years ago

'hard-coded' character encoding names should be canonical

Categories

(Core :: Internationalization, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: jshin1987, Assigned: jshin1987)

References

Details

(Keywords: intl, l12y)

Attachments

(2 files)

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.
Attached patch patchSplinter Review
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].
Attached patch firebird patchSplinter Review
same as attachment 134496 [details] [diff] [review] for firebird
Status: NEW → ASSIGNED
Summary: 'hard-coded' character encoding names should be canonical → 'hard-coded' character encoding names should be canonical
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)
Attachment #134996 - Flags: superreview?(blizzard) → superreview+
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 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+
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
I don't want to step into bryner' shoes, but the Firebird partition is now open.
a=me, go ahead! :-)
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...)
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. 
*** 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.

Attachment

General

Creator:
Created:
Updated:
Size: