Closed Bug 15264 Opened 26 years ago Closed 25 years ago

make the profile manager i18n friendly.

Categories

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

Product:
Core Graveyard
Component:
Profile: BackEnd
Platform:
x86
All
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: sspitzer, Assigned: gayatrib)

References

Details

(Whiteboard: [nsbeta2+])

I'm working on this now.
accepting. marking all milestone 11.
*** Bug 16856 has been marked as a duplicate of this bug. ***
Target Milestone: M11 → M13
Replace tague with naoki on the CC list.
*** Bug 21463 has been marked as a duplicate of this bug. ***
*** Bug 21463 has been marked as a duplicate of this bug. ***
*** Bug 21483 has been marked as a duplicate of this bug. ***
*** Bug 21484 has been marked as a duplicate of this bug. ***
*** Bug 21485 has been marked as a duplicate of this bug. ***
*** Bug 21362 has been marked as a duplicate of this bug. ***
QA Contact: gbush → amasri
This problem has been identified as the reason for a serious performance bug (#21362). The bugs were itemized because I was investigating that problem, not because I was trying to inconvenience anyone. Although support for two-byte characters has not yet been implemented in the profile manager, still its lack causes problems that are seemingly unrelated. I have asked momoi to include a description of the problem (#21362) and a workaround in the release notes.
*** Bug 21626 has been marked as a duplicate of this bug. ***
Severity: normal → critical
Priority: P3 → P1
Changing severity and priority after talking to Steve Elmer
Summary: make the profile manager i18n friendly. → [BETA] make the profile manager i18n friendly.
Assignee: sspitzer → selmer
Status: ASSIGNED → NEW
Reassign to selmer
steve, you'll want to talk to waterson to find out what needs to be done to root the registry datasource on the profile registry, instead of the registry it is currently hard coded to be rooted at.
Assignee: selmer → racham
Target Milestone: M13 → M14
Bhuvan, can this fit in the m14 list?
Status: NEW → ASSIGNED
This might call for noticeable changes. We can still keep it in M14.
*** Bug 17819 has been marked as a duplicate of this bug. ***
*** Bug 21481 has been marked as a duplicate of this bug. ***
Component: Profile Manager → Profile Manager BackEnd
Moving all Profile Manager bugs to new Profile Manager Backend component. Profile Manager component to be deleted.
Blocks: 24854
Ben, are there any backend changes required to finish this bug off?
making this dependent on the bug 23153 (ability to store international characters in the profile registry).
Depends on: 23153
Depends on: 23859
Need to be able to create intl profiles names, etc. especially for localized Beta1!
Keywords: beta1
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
Summary: [BETA] make the profile manager i18n friendly. → make the profile manager i18n friendly.
All the backend requirements will be tracked in the bug 23153. Assinging this bug to ben so that the required front end changes will be in place. This will track all the front end issues.
Assignee: racham → ben
Status: ASSIGNED → NEW
*** Bug 26890 has been marked as a duplicate of this bug. ***
Projected completion: 11-12 February.
Status: NEW → ASSIGNED
Whiteboard: [PDT+] → [PDT+] 02-11-2000
fixed, need a review.
reviewed, checked in.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Not fixed in 2000021509 build--still unable to create japanese user name in profile manager.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
what's the issue preventing you from doing this?
I think the problem here is that the backend is not yet ready to handle international characters properly. I am working on that and will check in a fix in a couple of days-- bug 23153.
thanks for the update, gayatri!
Whiteboard: [PDT+] 02-11-2000 → [PDT+] depends on 23153
Reassigning to myself as this is now dependent only on a backend issue on which i am working--23153.
Assignee: ben → gayatrib
Status: REOPENED → NEW
Status: NEW → ASSIGNED
The dependent bug 23153 is marked fix in hand, waiting for review. Please update the status whiteboard with a landing date for this bug resolution.
Debugged Ja char problem down to nsFileSpec isn't I18N ready. We give up for beta1.
Whiteboard: [PDT+] depends on 23153
PDT-
Whiteboard: [PDT-]
selmer, Pls be specific about how nsFileSpec is not I18N ready. We are making use of it in other areas. Is this a dependency upon bug 23153 which has the same comment?
Used nsIRegistry instead of the RDF datasource to read values from mozRegistry work done by dveditz. Marking fixed as 23153 as been fixed and checked in.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Changed QA contact to teruko@netscape.com. I tested this in 2000041206 Win32 build. When I create new profile, I put the Japanese name for profile name. It works fine. However, after I select the Japanese name profile in the profile manager, Netscape6 does not launch. The profile directory is not created. So, I reopen this.
Status: RESOLVED → REOPENED
QA Contact: amasri → teruko
Resolution: FIXED → ---
I will look into this.
Target Milestone: M14 → M16
*** Bug 36369 has been marked as a duplicate of this bug. ***
Nominating this bug for beta2.
Keywords: beta1 → nsbeta2
Whiteboard: [PDT-]
It is a known problem that is the directory name is in japanese this would not work as nsIFile is not i18n friendly yet. Does this error happen when the profile name is japanese and directory name english?
I tested this in 2000041909 M16 Win32 build. Creating Japanese profile name works fine. After I created Japanese profile name, the directory name "-1" is created under user50 directory. From Profile manager, if I select the Japanese profile, Netscape6 will launch. The problem now is the Profile manager will not create Japanese profile directory.
It is a known problem that the profile manager cannot create japanese profile directories. This is not a profile manager problem. It is a nsIFile problem. I just filed a bug on this -- 36463
Could we use pretty names in UI and ascii name for the real directory? Mail folders go for this approach!
Putting on [nsbeta2+] radar.
Whiteboard: [nsbeta2+]
Why hasn't this bug just been closed? The original problem has been solved. You are attempting to morph this bug into another bug and that's a Bad Thing(TM) so don't do that. This bug was about making profile manager even WORK with Ja machines. It works now, so I am closing this bug. I will open another bug for "Profile directories should be able to have Ja names." One of you must nominate that for nsbeta2 since I don't believe it should be.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
I already filed a bug that directory names are not being created with japanese names. bug #36463. (one of the comments above...)
This bug #36463 seems to have been marked fixed. I think we had a problem when creating directories from nsIFile. Would the javascript part of the solution fix nsIFile? And also profile manager used nsFileSpec and not nsIFile currently. The reason being at that time nsIFile did not support things like: nsCOMPtr <nsIFileSpec> defaultRoot; rv = locator->GetFileLocation( nsSpecialFileSpec::App_DefaultUserProfileRoot50, getter_AddRefs(defaultRoot)); if (NS_FAILED(rv) || !defaultRoot) return NS_ERROR_FAILURE; defaultRoot->GetFileSpec(&dirSpec); Is nsIFile ready for that now? I do not remember the bug# but I am sure it was filed at the time. Or what would be the alternate way to do this peace of code using nsIFile?
I tested this in 2000042611 Win32 and 2000042609 Linux build. I can create Japanese Profile name and the same Japanese Profile directory name is created. I need to test this in new Mac commercial build.
I verified this in 200042710 Mac build.
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.