Mozilla doesn't pick up proper files under <contentLocale>/bookmarks.html and *.rdf files even when <contentLocale> is specified to e.g. "JP". Try 0.9.1 JLP of www.mozilla.gr.jp with patch of bg 84443. 1. Apply patch of bug 84443 2. Start Mozilla 3. Install JLP form http://www.mozilla.gr.jp/jlp/ 4. Create new profile, select Japanese (ja-JP) and Region(JP) by the patch of bug 84443, contentLocale is now "JP" for the profile 5. Start with the new profile Open Bookmark menu. English bookmark items are listed. Under ~/.mozilla/<profile>/<...>/JP/bookmarks.html is installed but it seems that Mozilla doesn't pick up the files even when contentLocale is set to "JP".

I understand nsProfile::GetFile() should consider more one level for <contentLocale> when the directory exists. If this file exists, we should use this ~/.mozilla/<profile>/<...>/<contentLocale>/bookmarks.html instead of ~/.mozilla/<profile>/<...>/bookmarks.html However, it seems that when user did migration from 4.x profile, there is not <contentLocale> directory and migrated bookmarks is created just under profile directory. For the case, we should continue to use the file of profile directory. Is my understand correct? Anyway, I'll attach the patch.

Katakai-san - The code you added should be taken care of by nsProfile::DefineLocaleDefaultsDir(). Once a profile is set, that method is called, and it sets the file location NS_APP_PROFILE_DEFAULTS_50_DIR. This is the location that all of the getters in nsProfile::GetFile should use. That is how it should work. Otherwise, with your patch, we have a lot of duplicate code in nsProfile::GetFile(). There may be a problem with the DefineLocaleDefaultsDir() method. You would probably know better than I. One problem with DefineLocaleDefaultsDir() is that it is called when a profile is set. However, if somebody used a profile with a given locale, and NS_APP_PROFILE_DEFAULTS_50_DIR was correctly defined for that locale and then the user switched the locale from the View menu, NS_APP_PROFILE_DEFAULTS_50_DIR would need to be re-defined to the new locale.

reassign to katakai@japan.sun.com since he is working on this. mar moz0.9.2. cc tao and nhotta

QA -> jonrubin@netscape.com

Hi Conrad, thank you for comments, I was also thinking nsProfile::DefineLocaleDefaultsDir() should care this, but I found it's not user profile, it's system profile, e.g. NS_APP_PROFILE_DEFAULTS_50_DIR=bin/defaults/profile/US/ or /JP/. So, I think this is a correct way to get current user's profile dir by CloneProfileDirectorySpec() then add contextLocale (e.g. /US/ or /JP/) to the directory in nsProfile::GetFile(). Actually, NS_APP_PROFILE_DEFAULTS_50_DIR would need to be define properly when users select locale by View menu. But users will be required to re-start Mozilla after switching the locale so I don't think the current codes would cause any problem, NS_APP_PROFILE_DEFAULTS_50_DIR will be set properly at next startup. I don't still understand profile well, so please continue to give your comments if I have wrong understanding. Thanks.

It's not a matter of system profile vs. user profile, it's a matter of profile defaults vs. a profile. NS_APP_PROFILE_DEFAULTS_50_DIR means the directory from which a default file is supposed to be copied into the user's profile if the file does not exist when nsProfile::GetFile is called. If it does not exist, it will be copied from the locale-specific subdir of the defaults into the top level of the user's profile dir. That's what EnsureProfileFileExists does. There should not be locale-specific subdirs in a profile dir. There is a bug on that somewhere. The only time it happens is when a profile is made and the user does not specify a locale for the profile. In that case, the whole profile defaults is copied recursively.

Thanks, I understood now, > There should not be locale-specific subdirs in a profile dir. There is a bug Because I found JP/ directory under user profile, I was thinking locale specific bookmarks.html under JP/ should be used, but I was wrong. It seems that at the first creation of profile with specified UILocale and contentLocale, the locale specific bookmarks.html and *.rdf should be copied from NS_APP_PROFILE_DEFAULTS_50_DIR to top of user profile. I'll try to make new patch. However, as you mentioned before, I don't have any idea at switching content locale by View menu after once profile is created. We shouldn't switch user's bookmarks.html, *.rdf file because those files may be updated by users. Can we consider this case as spec? or is there any related bug already filed?

I work on this as part of bug 80230. *** This bug has been marked as a duplicate of 80230 ***

mass change, switching qa contact from jonrubin to ruixu.

Verified.