61554 - Mac-Japanese profile folder name is not created correctly on US system + Ja language kit

Status: RESOLVED DUPLICATE of bug 93140

(Core :: Internationalization, defect, P4)

Description

[Teruko Kobayashi]

You can create Japanese profile name on US system + Japanese launcuage kit, but the Japanese
profile folder is not created correctly.  

Steps of reproduce
1. Run Profile Manager
2. Create Japanese profile

Look at the folder under <hard drive>\document\Mozilla\Users50
   A folder is created, like "qpsesa.sit".  It should be created under the Japanese profile folder name. 

Netscape works under this profile.

3. Create another Japanese profile 
   It does not create any new folders under <hard drive>\document\Mozilla\Users50

Netscape does not work under this profile.  It seems the first profile is used.  

Tested 2000-11-08 Mac build.

Comment 1

[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 2

[msanz]

Conrad, please, change the priority in this bug, it should be a P1

Comment 3

[Conrad Carlen (not reading bugmail)]

Roy, is it possible that your patch for bug 58679 (the one to make the .js code
use unicodePath instead of path) may fix this?

Comment 4

[Roy Yokoyama]

Conrad: Teruko's comment from bug 58679 indicates that it fixes bug 61552, not
this bug.
Teruko: can you test this bug using the patched Mac build (from Naoki if he
still has it)?

Comment 5

[Conrad Carlen (not reading bugmail)]

After installing the Japanese language kit on US OS9, I was able to reproduce
this. I found this:
(1) When creating a profile with a Japanese name with the keyboard and script
set to Japanese, the input params to nsProfile::CreateNewProfile look right.
This means the front-end code is OK.
(2) In CreateNewProfile, NS_NewUnicodeLocalFile and nsIFile::AppendUnicode() are
used. Both of these routines have to map from Unicode to the file system
character set.
(3) This mapping is where the problem is. It is done by nsFSStringConversion
which is in nsLocalFileCommon.cpp. The problem is that under the US system with
the Japanese language kit, the file system charset is determined to be x-mac-roman.
(4) Because of this, the profile name which is suposed to be appended to the
profile directory has zero length (the japanese profile name can't be mapped
into x-mac-roman) and we have this problem.

The problem here is deep within the uconv code.

Comment 6

[nhottanscp]

I think this is a generic restriction we currently have. We are depending on
file system charset charset. For US MacOS, that's x-mac-roman even when the
language kit is installed. We have a similar restriction for locale mail folder
name (bug 39757), for example.
We may resolve it by using OS unicode file name support if that's available.
The bug can be reassign to nhotta or ftang since this is a generic i18n issue.

Comment 7

[Katsuhiko Momoi]

I'm wondering if we cannot use application locale
in this case for Mac only.

Comment 8

[Conrad Carlen (not reading bugmail)]

-> nhotta

Comment 9

[Makoto Kato [:m_kato]]

On currently Mozilla spec, JPN folder/filename cannot use on US system if you 
install JA-LANGKIT.
If this bug fixes, it must be unicode normalization of XPCOM/IO.  I suggest 
that mark as LATER or WONTFIX

Comment 10

[nhottanscp]

Reassign to ftang.

Comment 11

[Frank Tang]

teruko, please do the follwoing first
1. register the application as Japanese by using Language Registration
2. do the the following
does that make it work ?

Maybe we should throw a dialogbox out and warn the user if the profile name
cannot be convert to the system encoding and offer they a chance to change it.

Profile related issue. I don't think this is restrict to Mac. What will happen
on window when we use Active IME to input Japanese name in the profiler manager
? I assume similar thing will happen. Right?
If so, then this is an corss platform issue that we should throw warning dialog
out.

nhotta, please help. Mark this as P3.

Comment 12

[nhottanscp]

The problem also happens on my Windows 2000 EN.

Comment 13

[Teruko Kobayashi]

After I register the application as Japanese by using Language Registration, I
tested this.  However, I got the same result as before.

Comment 14

[Frank Tang]

Mark this as P4.

Comment 15

[Teruko Kobayashi]

Changed QA contact to [e-mail].

Comment 16

[Jaime Rodriguez, Jr.]

This sounds like a feature, and requires RFE. 

changing to nsbeta1-.

Comment 17

[Jon Rubin]

Changing myself to QA Contact.  This bug appears to have serious consequences,
because anytime a new Japanese profile name is created, the profile gets written
to the same .slt folder as previously created Japanese profiles.  The result is
that the new JA profile has the same settings as the old JA profile.  Some
consequences:

1) Bookmarks and Home page are set to the same setting as the older profile.
2) Start page does not appear when the newer profile is created.

Comment 18

[Jon Rubin]

I double-checked this on JA MacOS 9.1; the problem does not occur on the
Japanese Mac, so it seems to be a problem with the US OS.

Comment 19

[Andreas Becker]

mass change, switching qa contact from jonrubin to ruixu.

Comment 20

[Ying-Lin Xia]

Also see bug 93140.

Comment 21

[Thomas]

Is this bug still reproducible with current MacOS and new Mozilla versions?

Comment 22

[Wayne Mery (:wsmwk)]

do you still see this problem?  dup of bug 93140?