Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Make "More Encodings" submenus (intl.charsetmenu.browser.more{1,2,3,4,5}) non-localizable

RESOLVED FIXED in mozilla2.0b8



7 years ago
4 years ago


(Reporter: smontagu, Assigned: smontagu)


Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)



(1 attachment)



7 years ago
Currently the submenus under View | Character Encoding | More Encodings are localizable via the keys intl.charsetmenu.browser.more1, intl.charsetmenu.browser.more2, intl.charsetmenu.browser.more3, intl.charsetmenu.browser.more4, and intl.charsetmenu.browser.more5 in

This is currently blocking bug 369403 from getting in to 2.0, and will cause localization issues from bug 601429, which was already checked in. I don't see that this localizability is giving us any added value. Currently the vast majority of l10ns don't change the menu items at all. Those that do make changes can be divided into three categories:

1) Those who actually translate the charset names, e.g. x-mac-grĨki for x-mac-greek. I haven't yet tested with the localized builds, but I expect that this makes the menu items unusable. There is a localization note:

  ... If you're 
# adding charsets to your localized version, please refer to 
# intl/uconv/src/ file for the list of canonical 
# charset names and use canonical names exactly as listed there

but it's some distance away in the file, and maybe doesn't make it clear enough that "use canonical names" applies to the existing items as well as added charsets.
Localizations in this category: fy-NL, hr, ne-NP, ve

2) Those who change the order of the items within a sub-menu. zh-TW moves Chinese Traditional (Big5) to the top of the "East Asian" sub-menu, and ka moves Georgian (GEOSTD8) to the top of the "SE & SW Asian" sub-menu. I can understand the motivation for making these charsets more accessible, but I think the same purpose can be served by putting them into intl.charsetmenu.browser.static so that they appear already in the highest-level submenu.

3) Those who move items from one sub-menu to another. This includes hu and sl. hu only reverses the positions of iso-8859-1 and iso-8859-2, in other words puts iso-8859-1 in "East European" and iso-8859-2 in "West European". sl moves a whole group of charsets from "East European" to "West European": ISO-8859-2, windows-1250, IBM852, and x-mac-ce. These charsets are all labelled as "Central European", so I suppose they belong in one sub-menu as much as the other, but does the move really benefit users?

Note that the charset titles will remain localizable via

Comment 1

7 years ago
Created attachment 489145 [details] [diff] [review]

I removed all these prefs from firefox.js and xulrunner.js. Having them there was obsoleted by bug 297759.

I opened a thread in m.d.l10n to get feedback from localizers.
Assignee: nobody → smontagu
Attachment #489145 - Flags: review?(VYV03354)
Attachment #489145 - Flags: review?(VYV03354) → review+


7 years ago
Blocks: 369403

Comment 2

7 years ago
Comment on attachment 489145 [details] [diff] [review]

Requesting approval for 2.0, subject to no serious objections from m.d.l10n
Attachment #489145 - Flags: approval2.0?
We're past string freeze.
Attachment #489145 - Flags: approval2.0? → approval2.0-

Comment 4

7 years ago
(In reply to comment #3)
> We're past string freeze.

I don't see the connection. I'm removing localizable strings, not adding or changing them.
I believe that removing strings still shows up orange in the localization dashboard. Could we just land the patch without the string removal, and remove them after we branch?

Axel says he's in favor of taking the patch.

Comment 6

7 years ago
Benjamin, there's still a reasonable amount of string freeze breakage coming in the form of string additions and removals.

Given that this is really just cleanup, I'd rather have it.

It's going to be helpful to new locales coming in on the 2.0 branch once that's stable, too.

Comment 7

7 years ago
(In reply to comment #5)
> Could we just land the patch without the string removal, and remove
> them after we branch?

I guess that would work: since all.js no longer refers to for these prefs, the localized versions won't be used even if they're still in the file. Shall I add a note to the file to that effect?
I don't think we need to bother. As Axel said, removing strings isn't a big deal, and if we leave them now they're likely to be forgotten. If Axel's OK with it I don't see any problems landing that patch now.
Comment on attachment 489145 [details] [diff] [review]

And here I thought we were actually trying to get to the release endgame ;-)
Attachment #489145 - Flags: approval2.0- → approval2.0+

Comment 10

7 years ago
Last Resolved: 7 years ago
Resolution: --- → FIXED
Blocks: 467530
Flags: in-testsuite-
Target Milestone: --- → mozilla2.0b8
Depends on: 667512
No longer depends on: 667512


4 years ago
No longer blocks: 467530
You need to log in before you can comment on or make changes to this bug.