Closed Bug 78552 Opened 24 years ago Closed 4 years ago

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

Categories

(Core :: Internationalization, defect, P3)

defect

Tracking

()

RESOLVED INACTIVE

People

(Reporter: nhottanscp, Assigned: smontagu)

References

Details

(Keywords: l12y)

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.
Status: NEW → ASSIGNED
Keywords: l12y
Target Milestone: --- → Future
Target Milestone: Future → ---
Switching qa contact to jonrubin.
QA Contact: andreasb → 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
Keywords: nsBranch
I can take this while nhotta is gone...
Assignee: nhotta → jbetak
Status: ASSIGNED → NEW
mass change, switching qa contact from jonrubin to ruixu.
QA Contact: jonrubin → 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
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla0.9.5
Blocks: 99171
> 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
Keywords: nsbranchnsbranch-
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.
Target Milestone: mozilla0.9.5 → Future
Blocks: 107067
Keywords: nsbranch-
Nominating nsbeta1. Would like to see this get fixed for MachV. cc. rchen, yxia
Keywords: nsbeta1
jbetak's contract is up. Bulk move bugs to ftang
Assignee: jbetak → ftang
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
nsbeta1- this does not benefit l10n, helps i18n when adding new charset support
Keywords: nsbeta1nsbeta1-
-> to default owner (rather than ftang's WONTFIX)
Assignee: ftang → smontagu
Status: ASSIGNED → NEW
QA Contact: ruixu → amyy
Target Milestone: Future → ---
QA Contact: amyy → i18n

those strings don't exist anymore

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.