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
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.
I don't know about the original design, cc to tao.
Cata was the original author. IMO, move them into non-vendor files should be enough; don't move them back to *.js.
Tao, what do you mean by non-vendor files?
What I meant was files in mozilla that won't get overridden by netsccape's.
Do you have a suggestion? I am not familiar which files are available.
Switching qa contact to jonrubin.
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
I can take this while nhotta is gone...
mass change, switching qa contact from jonrubin to ruixu.
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
> 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.
minusing, too late for 0.9.4
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.
Nominating nsbeta1. Would like to see this get fixed for MachV. cc. rchen, yxia
jbetak's contract is up. Bulk move bugs to ftang
nsbeta1- this does not benefit l10n, helps i18n when adding new charset support
-> to default owner (rather than ftang's WONTFIX)