i18n profile name can not be displayed in local file path in profile manager

NEW
Assigned to

Status

()

Core
Internationalization
17 years ago
9 years ago

People

(Reporter: Yuying Long, Assigned: Jungshik Shin)

Tracking

({intl})

Trunk
Future
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

17 years ago
Build: 0102 trunk build on all platforms

Steps:
1. After installation, launch profile manager.
2. Click on create new profile.
3. In the profile name field, type some ascii characters and non-ascii
characters as a profile name.

Result:
You will see the non-ascii characters will not get displayed in the locale file
path while ascii characters will be displayed correctly. 
- see a followed screen shot.
(Reporter)

Comment 1

17 years ago
Created attachment 63260 [details]
screen shot.

See the Japanese characters in profile name and file path.
(Reporter)

Updated

17 years ago
QA Contact: teruko → ruixu
(Reporter)

Comment 2

17 years ago
Created attachment 63598 [details]
Another screen shot for Japanese at the beginning of the profile name

In this case, Japanese characters will display fine.
(Reporter)

Updated

17 years ago
Summary: i18n profile nama can not be displayed in local file path in profile manager → i18n profile name can not be displayed in local file path in profile manager

Comment 3

17 years ago
are you running on a Japanese platform or not?

Comment 4

17 years ago
I know what is the problem, it depend on the keypress to update the content

see
http://lxr.mozilla.org/seamonkey/source/profile/resources/content/newProfile1_2.xul

 41 <textbox id="ProfileName" value="&pnl2.defaultPName.label;"
onkeypress="updateProfileName();"/>

see what will happen if we change it to

 41 <textbox id="ProfileName" value="&pnl2.defaultPName.label;"
onkeyup="updateProfileName();"/>
Assignee: yokoyama → stephend

Comment 5

17 years ago
give to rchen. rchen- please try it.
Assignee: stephend → rchen
Keywords: intl

Comment 6

17 years ago
ok , we have two issue here.
1. if the system encoding (ACP on the window) cannot encode such character, we
won't show any character AFTER that character in the path. (yokoyama are looking
for a solution for this) 
2. if we could encode, we have the update timing issue. The timing is currently
depend onkeypress which do not include IME. We may need to change it to onkeyup.
I try this on my Win NT J. both chinese Global IME and native Japanese IME work.
We need to make sure it won't break the IME operation on Linux and Mac. Korean
failed because the reason 1. Not sure what will happen on the korean system

reassign this back to yokoyama. we should break this bug into two issue. One
deal with path name and one deal with updating from textbox.
add syd to the list. It seems other place IM also have such textbox sync issue. 
Assignee: rchen → yokoyama
(Reporter)

Comment 7

17 years ago
> are you running on a Japanese platform or not?

Yes. I was running on JA WinXP.  ( saw it when type chinese on chinese windows also)
Actually, I saw same problem when try to type Chinese and high ascii single byte
characters on WinXP-JA too.

But I just found: this problem happens when you first commit the Japanese or
Chinese words, when you hit the enter again, the Japanese or Chinese characters
will get displayed.

Comment 8

17 years ago
accepting
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.9

Comment 9

17 years ago
->nsbeta1
Keywords: nsbeta1

Comment 10

17 years ago
nsbeta1- per i18n triage
Keywords: nsbeta1 → nsbeta1-

Updated

16 years ago
Target Milestone: mozilla0.9.9 → mozilla1.0

Comment 11

16 years ago
move to future
Target Milestone: mozilla1.0 → Future
(Assignee)

Comment 12

15 years ago
I guess this bug was fixed. The filepath with characters not covered by the
current locale is a separate issue. 

Comment 13

13 years ago
I think both roy and me are off mozilla for more than 2 years. If these bugs are
still here now, I think the real stauts is 'won't fix'. If you want to reopen
it, please find a new owner for it first. 
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → WONTFIX

Comment 14

13 years ago
Mass Reassign Please excuse the spam
Assignee: tetsuroy → nobody

Comment 15

13 years ago
Mass Re-opening Bugs Frank Tang Closed on Wensday March 02 for no reason, all
the spam is his fault feel free to tar and feather him
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---

Comment 16

13 years ago
Reassigning Franks old bugs to Jungshik Shin for triage - Sorry for spam
Assignee: nobody → jshin1987
Status: REOPENED → NEW
QA Contact: ruixu → i18n
You need to log in before you can comment on or make changes to this bug.