bug 54998 has bee fixed, now we can switch UI message by -lang option. However, it seems that SelectLocaleForProfile() will not set Region. <NS1707:selectedLocale resource="urn:mozilla:locale:US:global-region"/> is remaining in user-locales.rdf. This also should be set to "JP", for example, by "-region" option.

I've attached the path. % mozilla -lang ja-JP -region JP will make ja-JP for language and JP for region by default. Tao-san, any comments?

Changing QA contact to jonrubin@netscape.com.

Is this for backend support of bug 65253?

Katakai san, I looked at the patch and I have questions. Both language and region are set by nsIChromeRegistry::SelectLocale, what does that mean? Does SelectLocale() accepet region or language? What if the user wants to set language and region, is that possible?

Hi Hotta-san, I understand SelectLocale() can accept both language and region as an argument. On profileManager or from View menu, we can select language and region. (But we can not specify both at the same time, we have to select "Japanese(JP)" for language, then "JP" for region. An argument of language or region is passed to SelectLocale(). Cc to hyatt.

So SelectLocale() implementation knows the argument is language or region? How is that possible, are the names different? I have other question. RDF data source, there is one for language which actually includes region too. When Tao separate language and region, did he also created separate data sources, one for language other for region?

Not sure how "US" or "en-US" is handled separately, but I think region content is defined in "-region" line in user-locales.rdf file, <R<NS1707:selectedLocale resource="urn:mozilla:locale:US:messenger-region"/> Also language is defined as, <R<NS1707:selectedLocale resource="urn:mozilla:locale:en-US:global"/> Both are in the same rdf file. Yes, I understand the question of Hotta-san, this is also my unclear point and want answer about SelectLocale() capability. Why will not SelectLocale() with "ja-JP" set language to "ja-JP" and region to "JP" ? If SelectLocale() has the capability (get "JP" from "ja-JP" then set "JP" for region), we don't have to call SelectLocale() twice. While I'm cheking profileManager .js and .xul, I understand there is a way that SelectLocale() has to be called per language and region. So, if SelectLocale("ja-JP") (will) sets "ja-JP" for language, "JP" for region we don't need this patch If not, We should call twice SelectLocale() per language and region (as this patch)

Katakai san, is there way for you to try SelectLocale("ja-JP") and see if that works?

The existing "-lang" option does this, mozilla -lang ja-JP call SelectLocale() with "ja-JP", bug which only changes the language part "en-US" to "ja-JP", "US" is still existing in user-locales.rdf file. That's why I submitted this new bug.

I looked at nsChromeRegistry.cpp but did not see any specific place for "language" and "region". I guess because they are stored separately so changing one would not affect the other. Please get a review by profile module owner and ask hyatt for super review.

I'd like to ask Module owners of Profile Manager to review the patch of http://bugzilla.mozilla.org/show_bug.cgi?id=80230 RFE: need -region option to switch Region at start up and want sr= from Hyatt. The patch enables to set region for user profile at command line. This is an additional changes for bug http://bugzilla.mozilla.org/show_bug.cgi?id=54998 RFE: UI language switching by command line option In bug 54998, SelectLocale() is called for "ja-JP" but it does not change "region" in user-locale.rdf, so mozilla will not start with fully localized. All "en-US" entries can be changed to "ja-JP", but "US" region is still existing, so we need to add -region option to set the value at startup. What I did in the patch, the changes are same when I changed for "-lang" option. - add "-region" option - check "-region" option, if exists, set the region to global locale (as same as -lang option) - After user selectes profile, set the region to the profile by SelectLocale(). (as same as -lang option) - If user selects language or region in profileManager, ignore the command line option (as same as -lang option) What I tested for the patch, - Use the language patch of 0.9 for Japanese - mozilla -lang ja-JP -region JP can change whole locale entries to japanese in user-locales.rdf in user profile - mozilla -lang en-US -region US can back the setting to US Regards, Masaki

The problem with this is that it is driven by a command line switch. Notice that the method which takes a command line, nsIProfileInternal::StartupWithArgs() is on the internal interface which is not supported for embedding. I would expect that embeddors would need this functionality. This code needs to be re-arranged so that it is exposed as a method on the nsIProfile interface. The command line switch can call this method. Basically, we don't want to add anything to the profile mgr which is useful to embeddors that can only be controlled from the command line.

> This code needs to be re-arranged so that it is exposed as a method on the > nsIProfile interface. Is that specific to -region option? Looks like other options like "-ProfileManager" are not done that way. http://lxr.mozilla.org/seamonkey/source/profile/public/nsIProfile.idl About SelectLocale() issue, I talked to hyatt yesterday. It's a historical reason that we have one function for UI and content. The implementation is generic not really know about UI and content internally. We can ask Tao later if we want to separate funtions for UI and content, also if we want to separate the RDF data also.

It would be good to have a method on nsIProfile such as: setLocaleForProfile(in wstring profileName, in wstring locale, in wstring region); This would do the work that is being done at the end of nsProfile::StartupWithArgs, and an embedding app could make use of it as well. Problem is, nsIProfile.idl has @status FROZEN. I'll have to check that one.

The method I mentioned should be put on nsIProfileInternal since nsIProfile is indeed frozen.

As mentioned elsewhere, "region" and "lang" are minsnomers. See bug 65241: ------ Additional Comments From bobj@netscape.com 2001-05-15 14:20 ------ > Now that I see the images of the spec, I think "region" is a misnomer. I agree. What has really been separated is UI v. content (not language v. region). Both UI and content may be language and/or regional dependent. Someone may want English UI for British or American regions (e.g., "-or" v. "-our", "-ize" v. "-ise"), or Swiss content in the French or German language. Before we add these APIs and command line options, we should settle on more correct terminology. Howabout "UILocale" and "contentLocale"? The terminology should be consistent with what is used in the prefs dialogs and menus. See bug 65241 and bug 65251.

TM to 0.9.2 per PDT triage (it's OK to check it in by Friday or after 0.9.1 branch is made).

>Howabout "UILocale" and "contentLocale"? Bob, are you proposing to separate the current one (nsIChromeRegistry::SelectLocaleForProfile) into two? I think we want wait Tao for that change. I think Katakai san can change nsIProfileInternal by adding a function which takes "UILocale" and "contentLocale".

Katakai san, do you agree with adding a method to nsIProfileInternal? If so, please rewrite a patch. Reassign to katakai@japan.sun.com.

nhotta> >Howabout "UILocale" and "contentLocale"? nhotta> Bob, are you proposing to separate the current one nhotta> (nsIChromeRegistry::SelectLocaleForProfile) into two? I think we nhotta> want wait Tao for that change. I agree. I just didn't want to choose bad names for options and interfaces which we will have to live with for years. nhotta> I think Katakai san can change nsIProfileInternal by adding a nhotta> function which takes "UILocale" and "contentLocale". Sounds good.

I want to make sure what I should do here, - change command line options from "-lang" and "-region" to "UILocale" and "contentLocale" - provide setLocaleForProfile(profileName, uilocale, contentlocale) in nsIProfileInternal - How about createProfileWizard.js? which is now calling createNewProfile(profileName, uilocale). Should I change those to profile.createNewProfile(profileName, uilocale, useExistingDir); profile.setLocaleForProfile(profileName, uilocale, contentlocale); Or is is better to provide createNewProfile() that takes contentlocale as argument? profile.createNewProfile2(profileName, uilocale, contentlocale, useExistingDir); - in setLocaleForProfile(), Should I call different method of nsIChromeRegistry per uilocale and contentlocale? I mean should I split nsIChromeRegistry::SelectLocaleForProfile() into two, nsIChromeRegistry::SelectUILocaleForProfile() and nsIChromeRegistry::SelectContentLocaleForProfile()? or Can I just call nsIChromeRegistry::SelectLocaleForProfile() twice?

> - change command line options from "-lang" and "-region" to > "UILocale" and "contentLocale" Yes. That makes sense. > - provide setLocaleForProfile(profileName, uilocale, contentlocale) > in nsIProfileInternal > - How about createProfileWizard.js? which is now calling > createNewProfile(profileName, uilocale). Should I change those to > profile.createNewProfile(profileName, uilocale, useExistingDir); > profile.setLocaleForProfile(profileName, uilocale, contentlocale); That depends. Should it be possible to change the uilocale of a profile after it is created? If that's the goal, yes. One problem with this is that when a profile was created in the past and a locale was specified, only a certain locale-specific sub dir of profile defaults were used for items such as localstore.rdf, panels.rdf, etc. If the uilocale is changed at some later time, what happens WRT these items? Or, do we want to say that the only time the locale of a profile can be set is when it is created? Then, it makes more sense to have profile.createNewProfile2(profileName, uilocale, contentlocale,useExistingDir); > - in setLocaleForProfile(), Should I call different method of nsIChromeRegistry Somebody else would know better about this.

I think nsIChromeRegistry change is not necessary for 0.9.2. Please file a separate bug for that and assign to tao.

I found we don't need to change createProfileWizard.js because it does the following already, 1.profile.createNewProfile(UILocale) 2.chromeRegistry.selectLocale(contentLocale); So, What I should do here is only > - change command line options from "-lang" and "-region" to > "UILocale" and "contentLocale" I'll file separate bug for nsIChromeRegistry issue. Does this make sense?

I've attached revised patch. Most codes are not changed from my previous patch, I changed the following, - -lang to -UILocale - -region to -contentLocale - variable related with "lang" to "uilocale" - variable related with "region" to "contentlocale"

The patch still has the problem I pointed out before: It is driven by command line switches. Although *what* the code is doing I believe is right, I have a problem with *where* it is doing it. The code near this comment: // update global locale if possible That sets the global locale so that when the profile mgr UI comes up, we have the right locale. That's a good thing. But, since it's global and is a function of chrome registry, why is it in the profile mgr? Because it was a convenient place to stick it. What if at some point in time the profile UI is not the first UI to be shown? It seems that this should be done by the application startup code before any UI may be invoked. I'm not sure about the use of a hash table to record which or whether a profile was created in a given locale. What about after the profile is created - on the second run of the profile? You could end up setting the locale of a profile when it has already been set to that locale. It could be useful to store the locale of a profile in its registry data. Then, if you had a method setLocaleForProfile(), it could check the input params against the values stored in the profile and prevent doing unnescesary work. I hope not to hold you up because this code is very useful. If you agree with my points, let's do them though. Otherwise, I'll end up doing it later :-/

Conrad, thanks for comment. I hope I understand your points. - The codes for install global locales should be moved to nsAppRunner.cpp so that any UI before calling InitializeProfileService() can be invoked with specified locale I added the codes just after cmdLineArgs->Initialize() in nsAppRunner.cpp. I think it's right place, but let me know if I'm wrong. - To avoid unnescesary work, we should check the current UI locale and content locale and if same, we shouldn't call SelectLocaleForProfile() I was thinking to use registry to keep UI locale and content Locale, but I found it would not work when the locales are changed outside of Profile Manager. e.g. changing by View menu. I'm thinking now that the locale data belong to chromeRegistry, not profile. So, before we call SelectLocaleForProfile(), get the current locale by chromeRegistry->GetSelectedLocale(); If different, then call SelectLocaleForProfile(). I don't still use registry. Please review again. Thanks.

Please ignore the prev patch. I had a mistake in below in nsAppRunner.cpp, UILOCALE_CMD_LINE_ARG for contentLocale should be CONTENTLOCALE_CMD_LINE_ARG. < + rv = cmdLineArgs->GetCmdLineValue(UILOCALE_CMD_LINE_ARG, getter_Copies(cmdContent)); --- > + rv = cmdLineArgs->GetCmdLineValue(CONTENTLOCALE_CMD_LINE_ARG, getter_Copies(cmdContent));

*** Bug 84443 has been marked as a duplicate of this bug. ***

*** Bug 85101 has been marked as a duplicate of this bug. ***

I'll attach new patch, now with fixes for bug Bug 84443 and Bug 85101. Please review. Even when users select UILocale and contentLocale on profileManager, contentLocale is not set to the profile (chrome/user-locales.rdf isn't updated properly) and locale specific files (e.g. bookmarks.html) are not installed properly to user profile directory. The problem is that we can not pass contentLocale to CreateNewProfile(), bookmarks.html will be copied in CreateNewProfile() but at the time, we only know "ja-JP" not "JP" as langcode, so profileManager tries to look the files under defaults/profile/ja-JP/. But it's now "JP". - Call SelectLocale() for locales specified by command line in InstallGlobalLocale() of nsAppRunner.cpp, which will set locales as global - provide nsIProfileInternal::CreateNewProfileWithLocales() interface so that createProfileWizard.js can call it with UILocale and contentLocale at creation - CreateNewProfileWithLocales() will call SelectLocaleForProfile() per UILocale and contentLocale - In CreateNewProfileWithLocales(), now we can find contentLocale and find locale specific profile directory. So we can copy default profiles (bookmarks.html and *.rdf) to top of user's profile directory. - When UIlocale=null and contentLocale=null, use specified locales by command line in CreateNewProfileWithLocales(), which are called by CreateDefaultProfile() and ProcessArgs() - When never locales set by profileManager and specified locales by command line exist, call SelectLocaleForProfile() at end of StartupWithArgs()

Nice! This looks like a comprehensive solution. Two questions: In CreateNewProfileWithLocales, if the UILocale and contentLocale are not passed as params, there is no command line, and we are not building with nsAppRunner (the case with embedding), what happens? In this case, does chromeRegistry->GetSelectedLocale() return anything? It looks like it will still work and that the profile defaults dir will be copied from the top level to the newly created profile dir. Is this right? At the end of CreateNewProfileWithLocales, as we did in CreateNewProfile, the defaults are copied into the new profile dir. Do we still need to do that? Since if the files don't exist, they get copied from the right locale defaults in nsProfile::GetFile() through EnsureProfileFileExists() If we didn't copy the files from defaults when creating the profile but waited until that particular file was requested, we could avoid a lot of file clutter in the profile dir. This point is no fault with your patch but something to consider for further improvement.

1. I understand chromeRegistry->GetSelectedLocale() returns the locale defined in chrome/user-locales.rdf at those cases. So, "en-US" and "US" will be returned when no command lines, not from ProfileManager. 2. Yes, there are some additional files 'chrome' under my defaults/profile/US/ also JLP from www.mozilla.gr.jp. katakai@xymo> pwd /export/home1/Mozilla/build/gcc/mozilla/dist/bin/defaults/profile/US katakai@xymo> ls bookmarks.html@ localstore.rdf@ panels.rdf@ chrome/ mimeTypes.rdf@ search.rdf@ katakai@xymo> ls chrome userChrome.css@ userContent.css@ katakai@xymo> The copies for those files should be done in CreateNewProfile() because it will not be done in EnsureProfileFileExists(). However, I could not find the files in 0.9.1 tarballs and xpi installer. I should check the directory can contain such files (other than bookmarks.html and *.rdf files) but, yes, as you mentioned, the codes will not prevent the patch. Conrad, can you add r=?

ccarlen or ben, can you review the patch? Thanks.

Doing it...

r=ccarlen as far as profile goes. Somebody with more chrome savvy should sr=.

I have a question. In nsProfile::CreateNewProfileWithLocales, if contentLocale exists subdir is used. I am not clear about this. Katakai san, could you explain this with an example? + if (contentLocale && nsCRT::strlen(contentLocale) != 0) { + // caller prefers locale subdir + nsCOMPtr<nsIFile> locProfDefaultsDir; + rv = profDefaultsDir->Clone(getter_AddRefs(locProfDefaultsDir)); + if (NS_FAILED(rv)) return rv; + + locProfDefaultsDir->AppendUnicode(contentLocale); + rv = locProfDefaultsDir->Exists(&exists); + if (NS_SUCCEEDED(rv) && exists) { + profDefaultsDir = locProfDefaultsDir; // transfers ownership

Hi Hotta-san, ContentLocale(Region) specific files, e.g bookmarks.html, *.rdf files and other files under defaults/profile/<contentLocale> will be copied to top of user profile dir here if exists. So we check e.g. defaults/profile/JP/ and defaults/profile/US/ here. If doesn't exist, the default dir defaults/profile/ is used, which is same with defaults/profile/US.

r=nhotta Is there a typo in the comment, contentLocale instead of UILocale? + rv = chromeRegistry->SelectLocaleForProfile(contentLocale, + NS_ConvertUTF8toUCS2(fileStr).get()); + // Remember which profile has been created with the UILocale + // didn't use gProfileDataAccess because just needed one time

Thank you hotta-san, I'll make changes for the typo. hyatt, could you super-review?

+ if (!aUILocale || !nsCRT::strlen(aUILocale)) { Please use aUILocale[0] instead of the more expensive strlen(). There are a few instances of that. Fix those and you have an sr=blizzard.

> ContentLocale(Region) specific files, e.g bookmarks.html, *.rdf > files and other files under defaults/profile/<contentLocale> will > be copied to top of user profile dir here if exists. > So we check e.g. defaults/profile/JP/ and defaults/profile/US/ here. > If doesn't exist, the default dir defaults/profile/ is used, which > is same with defaults/profile/US. This is excellent! I checked this by either chosing a locale when I made the profile and not choosing a locale and not using the command line options to set a locale. In all cases, when the defaults were copied, they were copied from a subdir of defaults/profile. In no case was the whole of defaults/profile copied recursively. Ending up with all those extra(unused) copies of files in the users profile dir causes confusion and is bug 56590. You can claim that one fixed along with this one :-) Another thing about this. If I removed the part at the end of CreateNewProfileWithLocales which copies the files from the defaults dir to the new profile dir, it still worked properly. This is because DefineLocaleDefaultsDir comes up with the same dir as the code in CreateNewProfileWithLocales. Katakai-san, I think you found that DefineLocaleDefaultsDir did not work for you. Reason probably is, in your code at the end of StartupWithArgs, DefineLocaleDefaultsDir will never be called. Shouldn't it?

I think this one is mid risk so I don't think this belong to limbo criteria. The positive impact is only on command line so it is neither a blocker for Mac/Win/Linux. However, this is a very important feature for Sun. I suggest the following nhott and jbetak- apply the patch and try the UI on Mac/Linux/Window the worst case (in additional to crash) could be is this patch break the language/region selection in profile . Let's do hard testing and decide what should we do.

I just applied the patch on W2K and went over some test scenarios with nhotta: It appears that the region content switching is partially broken without Katakai's patch. When attempting to switch regions from the "View" menu, the only change I could observe was the browser Home Page. When creating new a new profile, there would be no visible change resulting from selecting a particular content pack. With Katakai's patch the content/region switching seems to works as originally intended - the Sidebar content, default bookmarks, toolbar and Home Page all change as expected to the selected locale. Language switching seems to work, but we have no way to test it without up-to- date language pack. Maybe if we applied his patch to a Beta 1 build and tested with Beta language packs?

It appears that Katakai's patch improves the new profile creation process - it actually copies the appropriate locale-specific default bookmarks, Sidebar panel contents and other content-related files into the new profile. It does not change how the "View"-menu content-switching works. We do not overwrite the mentioned files in an existing profile, so the only observable change is the Home Page. I also tested the command-line addition - the troubling thing there is that although I start Mozilla with say mozilla -contentLocale JP, the content only changes with the second start of Mozilla. This is illogical and counter- intuitive and should change. Tentatively marking dependency on bug 62174, although there might be another way to resolve this issue.

Katakai san, I am testing your patch on Macintosh. In your comment on 2001-06-16 17:46 >So we check e.g. defaults/profile/JP/ and defaults/profile/US/ here. >If doesn't exist, the default dir defaults/profile/ is used, which >is same with defaults/profile/US. My question is who creates those 'JP', 'US' directory? I want to test that case but I don't know how to create those directories.

I just applied Katakai's patch to 0.9.1 to verify it with working language packs. Both the Profile Manager and View menu switch UI language and content locale as expected and without any problems. The only issue I observed on Windows is related to the application shutdown. I get an GPF on both the trunk and the 0.9.1 build. This might be related to the apprunner changes. I'll back them out and report on my findings.

Thank you very much for hard reviewing and testing, Yes, one problem is that there is no updated language pack of the currect tree for our testing. For example, for japanese locale, 0.9.1 language pack has been released on www.mozilla.gr.jp, but it doesn't work with the latest build. In my case, I tested the patch with *temp* language pack files which made from en-US and US files by updating rdf files and installed-chrome.txt, the running regchrome utility. > CreateNewProfileWithLocales. Katakai-san, I think you found that > DefineLocaleDefaultsDir did not work for you. Reason probably is, in your code > at the end of StartupWithArgs, DefineLocaleDefaultsDir will never be called. > Shouldn't it? I've verified DefineLocaleDefaultsDir() works fine, which can get the proper contentLocale e.g. 'US' or 'JP' even if we never call this at end of StartupWithArgs. RecursiveCopy() was performed with UILocale e.g. en-US or ja-JP which should be contentLocale 'US' or 'JP' at end of CreateNewProfile(). Once wrong files are copied, EnsureProfileFileExists() will never copy the locale specific files. That was problem. > My question is who creates those 'JP', 'US' directory? I understand 'US' is provided by default. After build is completed, we can find the directory under defaults/profile. 'JP' is provided by JLP. >I also tested the command-line addition - the troubling thing there is that >although I start Mozilla with say mozilla -contentLocale JP, the content only >changes with the second start of Mozilla. This is illogical and counter- Which platform did you use for testing? Actually I'm seeing this problem happens on Windows but it works well on UNIX. The first startup can switch the contentLocale properly on UNIX. I checked chrome/user-locales.rdf under user profile dir has been updated properly. So I guess that it's different problem but do we need to call some method after SelectLocaleForProfile() is called to reload .rdf files??? >The only issue I observed on Windows is related to the application shutdown. I >get an GPF on both the trunk and the 0.9.1 build. This might be related to the >apprunner changes. I'll back them out and report on my findings. I prepared NT box here and tested the patch, but I could not reprodice this problem. Is there any difference between NT and Win2K?

> >The only issue I observed on Windows is related to the > application shutdown. I > >get an GPF on both the trunk and the 0.9.1 build. This might > be related to the > >apprunner changes. I'll back them out and report on my findings. > > I prepared NT box here and tested the patch, but I could not > reprodice this problem. Is there any difference between NT and Win2K? Katakai-san, I saw this problem on two independent debug builds on my work as well as my home W2K machine and only mentioned this as a potential problem, which might merit further investigation. So far I seem to be the only person seeing this problem, which might be related to me not doing a full rebuild (only the profile and xpfe modules). > Which platform did you use for testing? Actually I'm seeing this problem > happens on Windows but it works well on UNIX. Katakai-san, I saw this on W2K. Naoki was testing Linux and Mac and so I can't comment on those two platforms.

GPF does not happen on my machine. I applied the patch to today's trunk (did full build for mozilla/profile and mozilla/xpfe/bootstrap). OS is Windows 2000 US.

I'm clearing the GPF warning - I just pulled a current trunk tree and did a complete rebuild. The GPFs don't appear anymore - I also double-checked the code for dangling pointers and couldn't really see anything wrong...

ready to ask to drivers for getting a=?

patch checked into trunk

the changes to nsAppRunner.cpp are bogus - you should not be hardcoding specific command line handlers there. Instead you should be making a command line handler in the profile DLL which handles this.

Alec - I suggested taking that command line processing out of profile mgr. It's setting the global locale using chrome registry. It has nothing to do with profile mgr and I objected to having it there.

I'm very sorry I could not check into 0.9.2. Anyway the patch has been checked into Trunk. Thank you very much for your great support.

Sorry, since this is not in moz0.9.2 branch yet. I reopen it . but nsbranch in the keyword. We should consider it into moz0.9.2 branch after we cut the moz0.9.2

This one is a mid risk one.

katakai- check in to trunk first and keep this bug open for moz0.9.2 check in

I think he already checked in to the trunk, see his comment on 2001-06-27 02:27.

PDT+ per pdt meeting. Katakai san- check it into moz0.9.2 branch.

checked into moz0.9.2 branch. marked as FIXED.

Tried verifying this on WinMe-Ja using 07-02-06-0.9.2; however, must launch browser twice using -ContentLocale switch for the region change to take effect. Is this a consequence of the dependency on bug 62174 (i.e. can this bug be verified before bug 62174 is fixed)? Also, how can this fix be verified on Mac? Can someone provide a test case for Mac?

Jon, have you tried Linux? Per Katakai-san's comments the restart is not required on UNIX. BTW I've added the dependency on bug 62174, but the real reason for the restart might be something else. Anyhow - just my 2 cents.

I understand Mac does not have a feature to pass command line option, right? If so, we don't need to test on Mac. However, this fix contains bug 87938 so we should test that scenario.

Mac can process a "pseudo" command line. If you create a text file, with creator being Netscape 6, and add the following line to that file: ARGS:-profilemanger then this is equivalent to './mozilla -profilemanager' on win32 and *nix.

jbetak, I finally got a Linux build that I could install and launch (07-03-18-trunk), but now I am not able to install a language pack from ftp.netscape.com. However, would a lang pack from there be valid with this build? Katakai-san's comments on 06-25 imply that it wouldn't be. If this is the case, where can I obtain a valid language pack from?

Let me clarify in my last statement: I am having trouble connecting and downloading from ftp.netscape.com because of network problems.

Here are the temp Japanese LPs, which can be applied to the current nightly. http://www.ash.ne.jp/~mal/mozilla/moz0.9.2plus-langjajp-070404.xpi http://www.ash.ne.jp/~mal/mozilla/moz0.9.2plus-regjp-070404.xpi # please note that panels.rdf under default/profile/JP seems to be # broken. Please replace with panels.rdf of US after installation, before testing. I've verified creating new problem with ja-JP and JP on ProfileManager works fine on both UNIX and Windows. However, I'm still seeing the problem that we need -UILocale and -contentLocale twice to switch the language by command line on *Windows* platform. UNIX works fine. - Creating profile with language on ProfileManager works fine on *both* UNIX and Windows - -UILocale and -contentLocale command line option works fine on UNIX - but -UILocale and -contentLocale command line option *does not* work on *Windows* - Switching language on Preference works fine at next startup on Windows So, it seems that SelectLocaleForProfile() could update rdf file properly but Mozilla could not load the language from the rdf files in the same startup. Can anyone know any difference between UNIX and Window around rdf loading??? Anyway, I'd like to suggest we file new separate bug for Windows platform.

Sorry, I have fixed panels.rdf for JP Region, http://www.ash.ne.jp/~mal/mozilla/091jp-panels.rdf and regjp.xpi. http://www.ash.ne.jp/~mal/mozilla/moz0.9.2plus-regjp-070504.xpi I also tried to change Japanese menu and content used -UILocale and -contentLocale option on win2k. 1. Install langjajp.xpi and regjp.xpi 2. Mozilla start up and exit 3. delete <user profile>/chrome/user-locales.rdf 4. "mozilla -UILocale ja-JP" command-line start up 5. Mozilla apply Japanese menu -contentLocale JP also success. When <user profile>/chrome/user-locales.rdf is *not* deleted, not success to change UI and content Language.

Katakai-san, Is the behavior that you see on UNIX consistent with what Maruyama-san has reported? It seems like a lot of steps to make this work. Do you agree?

The bug reported by Maruyama-san is Win only. I'm not seeing on UNIX. I have filed the separate bug as bug 91866.

Katakai-san, I checked today's branch builds (07-23) on WinMe-Ja and MacOS9.1 and found in both cases that it was necessary to start twice before I could see the Locale and Region changes take effect (I updated bug 91866 with this info). Also, on Mac, I could not see the initial browser window (I could see the menu only--I worked around this by using File>New Navigator Window, in which case I could then see a browser window). John Morrison thinks this could possibly be related to bug 91930, so I will check if this still happens in tomorrow's build. When I tried this on Linux, Profile Manager started okay (in the new UI when using -UILocale), but the browser would not start. I kept getting the following type of error: It's NOT UTF-16BE- byte 88(58) It's NOT UTF-16LE- byte 89(59) It's NOT UTF-16LE- byte 23(17) It's NOT UTF-16BE- byte 138(8a) It's NOT UTF-16LE- byte 167(a7) It's NOT UTF-16BE- byte 188(bc) xmlencoding detect- ISO-8859-1 It's NOT UTF-16BE- byte 24(18) It's NOT UTF-16LE- byte 187(bb) Have you seen this type of error?

Katakai-san, After more testing on Linux, I found that I could start the browser (using the -UILocale or -contentLocale switches) after a few tries (usually on the third or fourth try). Changing to en-US UI gave this type of error: xmlencoding detect- x-sjis xmlencoding detect- ISO-8859-1 This same error appeared when switching to JP region. Again, it was possible to successfully launch after 3 or 4 tries. I was testing this using the 07-23-branch build on Linux RH 7.1 JA.

The message 'xmlencoding detect- ...' shows up whenever a META charset element is found in the document. It is still enabled in the branch builds :-(. See bug 91205 & nsParser.cpp on the branch.

Jon, Which language pack are you using for branch testing? I found the recent nightly and branch build can not work with 0.9.2plus JLP from http://www.ash.ne.jp/~mal/mozilla/moz0.9.2plus-regjp-070404.xpi also branch build can not work 0.9.2 JLP from www.mozilla.gr.jp. I could not switch the language by preference dialog and view menu also. So I'm thinking it's generic problem around profile and RDFs.

Adding jaime to cc-list because of potential of trouble with language/region packs

Jon, on linux, the problem that browser doesn't launch right after migration is reported in bug 86707.

Jon, I tested with 07/24 linux branch build, it seems bug 86707 has been fixed. Browser does launch right after migration.

Katakai-san, I tried today's Linux and Mac branch builds (07-24-branch) and had no problem starting the browser. It appears that John Morrison was correct--the fix for bug 91930 appears to have resolved the problem that I was having yesterday launching on Mac (apparently using the locale switch was another way of hitting the problem in bug 91930, because I had seen the same problem with an earlier build). On Linux, the browser now launches on the first try, but I still see the "It's NOT UTF..." messages as the browser window opens. Would these messages also be related to bug 91205? So it looks like the language pack was not the problem. I think what you described sounds like a result of Tao's fix to bug 86807. I have been using an internal language pack that is compatible with recent branch builds. I'm not sure what fixed the launch problem, but Ji refers to bug 86707 as seeming to have been fixed. In any case, I will mark this bug as Verified on the Branch, since I can successfully launch using the -UILocale and -contentLocale switches, and the UI and content show up correctly. I will have to get a compatible lang pack to verify this on the trunk. As you stated, the changes take effect immediately on Linux; however, 2 starts are necessary on Win and Mac. This will be addressed in bug 91866. Thank you for your help with verifying this.

Hi Jon, Thank you very much for verification. I now understood the "version" of language pack is not matched with the currect branch so it failed on my environment. The version is "0.9.2" in branch. Maruyama-san, is it possible to prepare language pack for 0.9.2 branch with the language pack version string? The binrary of branch is under http://ftp.mozilla.org/pub/mozilla/nightly/latest-0.9.2/ I'm sorry I don't know how to create language patch with the version string. Regarding to "It's NOT UTF..." messages problem, I don't think it depends on language pack. It seems that the language pack uses non UTF-8 charset in some files. Maruyama-san, do you know about this?

OK! I had made Japanese Pack for 0.9.2-branch. http://www.ash.ne.jp/~mal/mozilla/moz0.9.2-langjajp-01072503.xpi http://www.ash.ne.jp/~mal/mozilla/moz0.9.2-regjp-01072503.xpi build ID: 2001072503 for Win, build ID: 2001072504 for Linux, both 0.9.2-branch build success to apply package on my evironment. Version string on bug 86807 is additional element of "contents.rdf" file in package. <RDF:Description about="urn:mozilla:locale:(locale name):(package name)" chrome:localeVersion="0.9.2"/> previous package is not contain version string element in contents.rdf.

Thank you very much, Maruyama-san!! I've verified the language pack can be applied to latest-092. I checked on Windows and Linux. I've verified, - bookmark can be localized in new profile - language can be switched when creating new profile - UILocale and contentLocale switch at start up But, yes, as bug 91866, I'm seeing the problem that the locale could not be switched at the first startup on Windows. Linux is OK.

mass change, switching qa contact from jonrubin to ruixu.

Verify fixed with 0.9.3+, UILocale and contentLocale can be switched, but cannot be switched at the first startup on Windows (bug 91866). (Also tried 0.9.4, but no Language Pack and Region Pack are available for 0.9.4)