[i18n] new (non migrated) profiles get ~/.mozilla/<profile>/en-US/*.rdf



18 years ago
3 years ago


(Reporter: sspitzer, Assigned: ccarlen)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: [rtm-])

when I create a new profile, (not migrate it) I get this:

with a migrate profile, I just get

one of those is wrong.  for en-US users, it doesn't hurt anything.  but I'm
worried that for other locales, it means they get the default english rdf files.

assigning to racham to investigate.
marking rtm.  
Keywords: rtm

Comment 2

18 years ago
Hi, Seth:

The 2nd one is not used. They are copied over to new profile because profile
code recurively copies all files under bin/defaults/profile/*. This will happen
when "language/region" is not explicitly selected.

It will not cause malfunction of the product; redundent files are copied -- that
is all.

Comment 3

18 years ago
The first case Seth mentioned was a side-effect of RecursiveCopy we do to sump
all default profiles into a newly created profile directory. When the
localization scheme came in, we added some locale folders under default profile
directory and they are also started getting copied along with other default
files. So, we have some additonal folders sitting in there. Utlimately, all we
access are the files under the profile directory and any locale subfolders at
runtime. So, presence of en-US is not harmful anyway as tao mentioned. This is
the case for the users who skip the Region Selection during the new profile
creation. This is a bug and we need to avoid copying redundant files.

For the users, who select a particular region, the directory from which the
default files to be copied will be that region directly (say, if a user selects
en-US region, we ask profile code to copy default files from the en-US
folder..not one onelevel above like for all default cases) and we won't have
copy any additonal folders here.

Coming to the migrated profile cases, we simply pick the files from
defaults/profile folder. We will always have localized content in this folder
depending on the locale build you downloaded. If you are ja user and downloaded,
en-Us build, you will get default en-US profile files and if you are a ja user
and downloaded japanese build you will get all japanese default files into your
migrated profiel directory. So, it really depends on the build user gets and
that's users choice. We provide default files depending on his locale choice.
We could do smarter things like finding out locale of the machine and get those
default files and that is subjected to discussion again if we have to give the
user who downloaded a english build, default japanese profile files.

So, I think this bug should not be a major concern for rtm.

Comment 4

18 years ago
rtm-, no harmful effects to user experience.
Whiteboard: [rtm-]

Comment 5

18 years ago

Is there an interaface in the locale services to determine whether a given a 
string is any of the locale names...? If there is one, that would help us solve 
this problem with ease as we can do that check on the directory name and skip 
those dirs in the recusrive copy....

Comment 6

18 years ago
Doing a mass reassign to Conrad Carlen.

Conrad is going address all current and upcoming profile manager issues. Please
do not hesitate to involve me in any of the issues.
Assignee: racham → ccarlen

Comment 7

18 years ago
Tao, I still have the same question that Bhuvan asked on 2000-11-30. It would be
good to get rid of this file clutter. If I could identify a locale sub-dir in
the defaults dir, I could skip copying it.
Target Milestone: --- → mozilla0.9

Comment 8

18 years ago
Hi, Bhuvan and Conrad:

It seems to me what you really need is a list of installed locale porvider names.

There is no single api to provide such information as far as I know.
You can retrieve this information from chromeRegistry, though. You can consult 
hyatt or waterson for how to get this info.

Comment 9

18 years ago
-> mozilla1.0
Target Milestone: mozilla0.9 → mozilla1.0
*** Bug 78472 has been marked as a duplicate of this bug. ***

Comment 11

18 years ago
this bug has a broader impact - it seems - since there are copies of 
boomarks.htm, etc. etc. And also userChrome.css and userContent.css are getting 
placed in the wrong .../chrome directory rendering them useless 
> And also userChrome.css and userContent.css are getting placed in the wrong

That's bug 37642. It has nothing to do with profile mgr but is a makefile problem.
In particular, see attachment 32917 [details] [diff] [review] on that bug. That will fix the problem of
files you mention being in the wrong place.
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
Target Milestone: mozilla1.0 → mozilla1.0.1
-> future
Target Milestone: mozilla1.0.1 → Future
QA Contact: agracebush → profile-manager-backend
This bug is filed in a bugzilla component related to pre-Firefox code which no longer exists. I believe it is no longer relevant and I am therefore closing it INCOMPLETE.

If you believe that this bug is still valid and needs to be fixed, please reopen it and move it to the Toolkit:Startup and Profile System product/component.
No longer blocks: 1243899
Last Resolved: 3 years ago
Resolution: --- → INCOMPLETE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.