85101 - Mozilla can't pick up <contentLocale>/bookmarks.html and *.rdf

Status: VERIFIED DUPLICATE of bug 80230

(Core :: Internationalization, defect)

Description

[Masaki Katakai]

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".

Comment 1

[Masaki Katakai]

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.

Comment 2

[Masaki Katakai]

Attachment: patch for nsProfile::GetFile()

Comment 3

[Conrad Carlen (not reading bugmail)]

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

[Frank Tang]

reassign to [e-mail] since he is working on this. mar moz0.9.2. cc 
tao and nhotta

Comment 5

[Andreas Becker]

QA -> [e-mail]

Comment 6

[Masaki Katakai]

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

[Conrad Carlen (not reading bugmail)]

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.

Comment 8

[Masaki Katakai]

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?

Comment 9

[Masaki Katakai]

I work on this as part of bug 80230.

*** This bug has been marked as a duplicate of 80230 ***

Comment 10

[Andreas Becker]

mass change, switching qa contact from jonrubin to ruixu.

Comment 11

[Rui Xu]

Verified.