I just tested the InstallTrigger.installChrome() function in JS code. Here is what I got: 1. It downloaded the zip file into the user profile's "Chrome" directory but not unzipped. 2. I didn't see it update either all-locales.rdf or user-locales.rdf. 3. The client ran into a few assertions and then died. The problem is reproducible on both NT and Linux w/ 05-15-2000 builds. I am also attaching the localeSwitcher.xul and ja-JP.zip file.

To reproduce: 1. place "localeInstaller.xul" in "bin\chrome\packages\widget-toolkit\global\content" 2. place "ja-JP.zip" in "bin\chrome". 3. Launch mozilla and choose a profile, say "moz-m16-dbg". 4. Load "chrome://global/content/localeInstaller.xul" from the browser window, 5. if you run into any assetion, ignore them... 6. You shall see a dialog prompting whether to download and install the langpack, "ja-JP", click "OK".. 7. You will see what I have described in the "Description" section of this bug report. Let me know if you need help reproducing the bug.

Thought that I added "nsbeta2" ? Add it now.

At one point using jar: URL's for chrome worked; the latest skins spankage seems to have changed this so I have to go back and explode the archives now. I was hoping to avoid that, just use jar: URLs even though it would be slow until the caching was implemented. But now it's looking like I'll have to go in and explode the archives, and then switch it back later. Drat.

Just for clarification: (1)in "Description field" is what I observed; not necessary a bug. I knew that the plan is to use jar which is not supposed to be "unzipped". But, if we will not use JAR for PR2; yes, please unzip the zip archive unless we can extra files from zip without decompressing it.

Putting on [nsbeta2+] radar for beta2 fix.

This actually works. Right now I'm getting a crash at the end though :-( but when restarting the chrome is correctly selected. I note that the new language-switcher menu item asks users to restart after switching so this may be a known bug. Will take a brief look at the crash and then probably close this one.

I commented out the call to ReloadChrome() which was crashing. So now the locale can be installed and selected, but the selection will only take effect when new XUL is loaded. Generally on a restart, but if you hadn't loaded Mail (for example) you could open Mail and get the new locale. Installing profile chrome appears to hide the globally-installed chrome of the same type (skin, locale or package). This is bug 45951 -- please vote for nsbeta2+ status for that bug.

used testcase noted here-did not see the files all-locales.rdf and user-locales.rdf updated- should I? also when restarting with this profile I see an XML parsing error:undefined entity, line nubmer 141, column 29 accesskey="&reloadCmd.accesskey:"

I'm not sure the test case attached is still a valid one, but the XML error you described sounded like a UI thing, not a manifest.rdf parsing error. How far did you get into the process before the error? I'm relatively sure Tao's XUL is not a good way to test since it clouds the results with uncertainty. I believe jimmy and/or david have test cases for installChrome, or you could write a simple HTML page that does the raw trigger: InstallTrigger.installChrome(InstallTrigger.LOCALE, "url://to/locale/zip","name-of-locale");

Yes, the attached xul file is not a good test case. Please follow dan's suggestion to verify the fix.

tao, do you think you could post a url for a new version of ja-JP or some other translation that works? [for once I wasn't the one who made the accesskey requirement]. Thanks.

The ja-JP files I have at hand are not up-to-date. For Mozilla build, we rely on MLP contributor to submit translations. Please see the project page in the URL field. Also, I posted an instruction for making a ja-JP pack that Mozilla can use yesterday to news://news.mozilla.org/netscape.public.mozilla.l10n.

using the trigger as noted above, and after relaunching netscape 6, same parsing error is received- see bug 46534. I think this bug is fixed- please reopen if it recurs