78552 - Some of charset menu strings have to move from .property to .js

Status: NEW

Description

[nhottanscp]

Some charset menu resources are consistent through localized builds and do not
have to be located in navigtor.properties. Having them in .property
files causes a maintenance problem as we have both mozilla and netscape versions
of navigator.properties.

List of strings which need to move:
intl.charsetmenu.browser.more1
intl.charsetmenu.browser.more2
intl.charsetmenu.browser.more3
intl.charsetmenu.browser.more4
intl.charsetmenu.browser.more5
intl.charsetmenu.mailedit

Comment 1

[bobj]

This will fix it for the non-localizable resources, but even the localized
resources should not live in multiple versions (e.g., mozilla and netscape)
of the same file.

Comment 2

[nhottanscp]

I don't know about the original design, cc to tao.

Comment 3

[tao]

Cata was the original author. IMO, move them into non-vendor files should be
enough; don't move them back to *.js.

Comment 4

[nhottanscp]

Tao, what do you mean by non-vendor files?

Comment 5

[tao]

What I meant was files in mozilla that won't get overridden by netsccape's.

Comment 6

[nhottanscp]

Do you have a suggestion? I am not familiar which files are available.

Comment 7

[Andreas Becker]

Switching qa contact to jonrubin.

Comment 8

[tao]

Naoki:


If you are sure that we'll never need to localize these entries, yes, please
move them back to *.js and put some comments there.

thx

Comment 9

[[e-mail] (away - not reading bugmail)]

I can take this while nhotta is gone...

Comment 10

[Andreas Becker]

mass change, switching qa contact from jonrubin to ruixu.

Comment 11

[[e-mail] (away - not reading bugmail)]

I believe we can't really move this into JS. Cata is reading these property 
files from the charset menu C++ backend and changing that would be an 
unnecessary risk at this point.

I agree with Tao's position though: we could move all these into a .properties 
file, which is - unlike navigator.properties - not present in both Mozilla and 
Netscape. This would be reasonable even in the short term, however I'd suggest 
doing it later on the trunk do diminish the risk of regressions on the trunk.

http://lxr.mozilla.org/seamonkey/search?string=intl.charsetmenu.browser.mo

Comment 12

[[e-mail] (away - not reading bugmail)]

> causes a maintenance problem 

the original complaint was about increased maintenance by having both open-
source and commercial versions of these strings. I believe the best course of 
action would be to move all offending entries to a .properties file, which is 
not overridden by a commercial version and exists only once. An example of such 
a file would be metadata.properties.

http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/locale/en-
US/metadata.properties

I also happen to believe that currently there is no really suitable .properties 
file and we might end up creating a new one, which would just contain the 
charset menu strings. I'll create a patch pursuing this.

Since this issue is a technicality and doesn't impede the localizability in any 
way, I'd suggest dropping the branch checkin requirement.

Comment 13

[msanz]

minusing, too late for 0.9.4

Comment 14

[[e-mail] (away - not reading bugmail)]

I don't have a good non-vendor-specific place to hold charset menu strings, but 
hope to change the way things work in a larger regesign of the charset menu.

Comment 15

[Michele Carlson]

Nominating nsbeta1. Would like to see this get fixed for MachV. 
cc. rchen, yxia

Comment 16

[Frank Tang]

jbetak's contract is up. Bulk move bugs to ftang

Comment 17

[nhottanscp]

nsbeta1-
this does not benefit l10n, helps i18n when adding new charset support

Comment 18

[Adam Hauner]

-> to default owner (rather than ftang's WONTFIX)