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

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Profile: BackEnd, defect, P3)

Description

[(not reading, please use [e-mail] instead)]

when I create a new profile, (not migrate it) I get this:
~/.mozilla/<profile>/panels.rdf
~/.mozilla/<profile>/en-US/panels.rdf

with a migrate profile, I just get
~/.mozilla/<profile>/panels.rdf

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.

Comment 1

[(not reading, please use [e-mail] instead)]

marking rtm.  

Comment 2

[tao]

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

[racham]

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

[selmer (gone)]

rtm-, no harmful effects to user experience.

Comment 5

[racham]

Tao,

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

[racham]

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.

Comment 7

[Conrad Carlen (not reading bugmail)]

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.

Comment 8

[tao]

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

[Conrad Carlen (not reading bugmail)]

-> mozilla1.0

Comment 10

[Conrad Carlen (not reading bugmail)]

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

Comment 11

[andreww]

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 

Comment 12

[Conrad Carlen (not reading bugmail)]

> And also userChrome.css and userContent.css are getting placed in the wrong
.../chrome

That's bug 37642. It has nothing to do with profile mgr but is a makefile problem.

Comment 13

[Conrad Carlen (not reading bugmail)]

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.

Comment 14

[Asa Dotzler [:asa]]

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 
moved)

Comment 15

[Conrad Carlen (not reading bugmail)]

-> future

Comment 16

[Benjamin Smedberg]

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.