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

Status: RESOLVED FIXED

(Core :: Internationalization: Localization, defect)

Description

[Simon Montagu :smontagu]

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 intl.properties.

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/charsetalias.properties 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 charsetTitles.properties.

Comment 1

[Simon Montagu :smontagu]

Attachment: Patch

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.

Comment 2

[Simon Montagu :smontagu]

Comment on attachment 489145 [details] [diff] [review]
Patch

Requesting approval for 2.0, subject to no serious objections from m.d.l10n

Comment 3

[Benjamin Smedberg]

We're past string freeze.

Comment 4

[Simon Montagu :smontagu]

(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.

Comment 5

[Benjamin Smedberg]

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

[Axel Hecht [:Pike]]

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

[Simon Montagu :smontagu]

(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 intl.properties 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?

Comment 8

[:Gavin Sharp [email: [e-mail]]]

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 9

[Benjamin Smedberg]

Comment on attachment 489145 [details] [diff] [review]
Patch

And here I thought we were actually trying to get to the release endgame ;-)

Comment 10

[Simon Montagu :smontagu]

http://hg.mozilla.org/mozilla-central/rev/7034c271ebd2