Observed on 2000-05-13-20-M16 comm build. Steps to reproduce: 1.Lauch the profile manager and Create a new profile 2.Start Netscape with the new profile. 3.Select Task -> Mail via Menu bar. 4.Select Edit -> Mail/News Account Setting via Menu bar. 5.Check "Other ISP or email provider and leave Existing Mail acount checked, too in the New Account Setup dlgbox. 6.Then Click Next button and come up the Identity dlgbox. Actual result: you will see "Your Name" text field is automatically filled with garbled characters in the dlgbox. Respected result: "Your Name" text field should be empty.

actually, I believe on mac we auto-fill with your username from the system... seth? We do have this on mac right?

Then respected result should be: username should be auto-filled with correct one instead of garbled one.

yes, on the mac we use internet config to find out info about the user for the wizard. what is the garbled text? perhaps sfraser has some ideas.

Hi,Montse: this is not international,it is a general account manager issue,but it maight be affected by IME because I had input Ja characters in this field before. So I copy it to you. I am not sure if it is because that or not. I will explore more about this after the PR2 mail status report.

davidm did the mac IC code.

did you happen to enter JA characters into Internet config? maybe we're getting i18n unfriendly data from Internet Config? Can you copy/paste the string that's getting pre-filled? Maybe someone here will recognize it (I'm wondering if it's utf8 or something)

I use Internet Config 1.4 (which came with 4.5-Japanese version). in English Mac 8.6 -- I know this isn't optimal way to look at this problem but one can find some interesting facts about it even in this method. I see that "Internet Preferences" I save when I enter a Japanese name gets saved in Shift_JIS -- just as I entered the characters using JLK. I also looked at what I entered using this old Internet Config application with Internet Control Panel item which comes with English Mac OS 8.6. It looks like Japanese Shift_JIS displayed using an English font. I also looked into the file itself using Resorcerer, it seems that Shift_JIS data are saved as they are not in UTF-8 or some other converetd encoding. It is worthwhile noting that the Internet Preferences file has a "vers" resource which has "country" setting. Naturally mine is set to US. Now when Mail Account wizard pulls in that name, it is unreadable in my case also just as cwang reports. So I changed the country setting in the vers resource to Japan and tried it again and there was no difference. My initial sense is that Mozilla is not paying attention to what language system it is running on or what vers country setting Internet Preferences file is in. So here are some questions: 1. What data encoding Account Wizard is expecting to get out of the Internet Preferences file? What aassumption is made as a default for the encoding of the data? 2. Is the Mail Account Wizard converting data in the Internet Pref file based on the System charset or Internet Pref file's country setting? I'm not completelyt sure until I check cwang's Japanese Mac OS but it seems that we should be converting from a) system charset, or b) default encoding for the country setting, into Unicode required by the layout. Maybe we are not doing that?

Kat assumption about our treating all IC data as ascii ( macroman or iso-????) is correct. Some mac person ( not me ) should be able to fix this rather than alecf.

I checked Internet Control Panel utlility for Mac OS-Japanese 8.6. It is saving into the system charset for the IC pref file -- for Japanese Mac, that would be Shift_JIS. I think we have an i18n service to query the system charset.

Are you sure IC is storing the data as Shift-JIS? I would expect it just to store multibyte text in the system script code, not using any kind of encoding.

Since users will most likely input Japanese characters into the name section of Internet Config and Mail Account will botch that now, I'm nominating this for Beta2.

I think the system script code for Japanese Mac is Shift_JIS. Is there another candidate?

By the way, I can copy from the data fork portion of the IC pref file and paste into a Japanese editor like TeachText and see them right. I tihnk this would be the case only if it is in Shift_JIS.

I forgot to write in the keyword, nsbeta2.

Kat, I'm going to reassign to you - I know you're not the right person, but I know you can find him/her :)

Bob? This is tour for now.

I meant to say, "..this is yours for now."

Shift-JIS is a character encoding. Native Japanese text on Mac is not encoded in any way; you just get the raw multibyte text string that you can feed directly to DrawString (assuming the font is set to a japanese font).

Simon, I think we are saying the same thing. You're right, I don't think IC is doing any "en-coding" of its own. It's probably passing the received bytes through into a file. In that case, I think assuming that it is in system chaset will get us a right result for most cases we care about.

On Macs, just as "latin" text is encoded as MacRoman, Japanese text is encoded as Shift-JIS. When you set the script to Japanses the Mac APIs treat the text strings as Shift-JIS (as opposed to MacRoman or something else). We do have code to determine the Mac system script. And can use that info to correctly convert the strings to UTF-8. I'll find someone to look into this and at least provide a patch. I think this should be straight forward.

[nsbeta2-]

qa contact to momoi

Frank, Pls find a Mac guy to help with this one.

Simon Fraser 2000-05-16 13:04: >Are you sure IC is storing the data as Shift-JIS? I would expect it just to store >multibyte text in the system script code, not using any kind of encoding. The multibyte encoding in the Japanese system have script code smJapanese- which is the same as Shift_JIS. They are the same. Simon Fraser 2000-05-16 13:17: >Shift-JIS is a character encoding. Native Japanese text on Mac is not encoded >in any way; you just get the raw multibyte text string that you can feed >directly to DrawString (assuming the font is set to a japanese font). >Native Japanese text on Mac is not encoded in any way; Incorrect- Native Japanese text Mac is stored as Shift_JIS CJKV Information Processing, O'Reilly, Ken Lunde, ISBN1-56592-224-7, page 175 > Shift-JIS Encoding- JIS X 0208:1997 >Shift-JIS encoding, origionally developed by Microsoft Corporation, is widely >implemented as the internal code for a variety of platforms, including >Japanese PCs and MacOS-J (including Japanese Language Kit). ... Can someone point out which file in which directory program w/ IC ?

I think this is P1 M18

The following code might be the problem- xpfe/appshell/src/nsUserInfoMac.cpp 42 char* cName; 43 nsresult result = ic.GetString( kICRealName, &cName ); 44 if ( NS_SUCCEEDED ( result ) ) 45 { 46 nsString fullName; 47 fullName.AssignWithConversion( cName ); 48 nsMemory::Free( cName ); 49 *aFullname = fullName.ToNewUnicode(); line 47 assign char* to nsString by assuming cName is only in ASCII or ISO-8859-1. We probably need to figure out what charset cName is and convert to Unicode properly. 75 if (atOffset != kNotFound) 76 tempString.Truncate(atOffset); 77 78 *aUsername = tempString.ToNewCString(); 79 return NS_OK; same problem, it assume the IC accept ASCII or ISO-8859-1 and convert Unicode from nsString to char* by using ToNewCString(). This is wrong. Instead, we should find out what the charset InternetConfig accept and convert the Unicode to it properly. sspitzer and sfraser - We probabaly need your help to find proper information about InternetConfig to fix it. Can you point us some URL about InternetConfig URL ?

add garywade to the list.

InternetConfig, alas, is not written with i18n in mind. I think the best we can do is assume that the text coming from IC is in the system script.

reassign to nhotta. nsbeta3- per i18n bug meeting. we may need to look at this bug later again. Mark it as M20

reassign to nhotta. We may need to fix this. Consider lower priority for now.

QA contact to marina.

the "Your name" field is still prefilled when creating a new account, in case the previous account name was JA it'll be prefilled with garbage

Still a problem ? (reporter and assignee are long gone.)

(In reply to comment #33) > Still a problem ? > > (reporter and assignee are long gone.) > When Japanese is used for the account name(description) of OS, "Your name" field is a blank. When description is only English, this is set as a default value. # It is not login ID. # Japanese cannot be used for login ID. I think that you should treat it with another file when the thing that a Japanese user-name is set to the default value is preferable. Mac OS X 10.3.9 Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a6pre) Gecko/2007062702 SeaMonkey/2.0a1pre

This still happens for TB and SM. My Full Name contains an umlaut which gets broken when extracted via nsIUserInfo. Using Venkman on aw-identity.js::checkForFullName, I get userInfo.fullname == "Karsten D\x9Fsterloh" - but \x9F is no ü in Unicode/UTF-8, but some tremaed uppercase Y. In fact, this seems to suggest "Mac OS Roman" as the encoding...

Should be resolved by bug 394901.

(In reply to comment #36) > Should be resolved by bug 394901. Indeed.