Closed
Bug 85101
Opened 23 years ago
Closed 23 years ago
Mozilla can't pick up <contentLocale>/bookmarks.html and *.rdf
Categories
(Core :: Internationalization, defect)
Core
Internationalization
Tracking
()
mozilla0.9.2
People
(Reporter: masaki.katakai, Assigned: masaki.katakai)
Details
Attachments
(1 file)
4.69 KB,
patch
|
Details | Diff | Splinter Review |
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".
Assignee | ||
Comment 1•23 years ago
|
||
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.
Assignee | ||
Comment 2•23 years ago
|
||
Comment 3•23 years ago
|
||
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.
Comment 4•23 years ago
|
||
reassign to katakai@japan.sun.com since he is working on this. mar moz0.9.2. cc tao and nhotta
Assignee: nhotta → katakai
Target Milestone: --- → mozilla0.9.2
Assignee | ||
Comment 6•23 years ago
|
||
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.
Comment 7•23 years ago
|
||
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.
Assignee | ||
Comment 8•23 years ago
|
||
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?
Assignee | ||
Comment 9•23 years ago
|
||
I work on this as part of bug 80230. *** This bug has been marked as a duplicate of 80230 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Comment 10•23 years ago
|
||
mass change, switching qa contact from jonrubin to ruixu.
QA Contact: jonrubin → ruixu
You need to log in
before you can comment on or make changes to this bug.
Description
•