If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Profile migration does not migrate Accept Language and default charset



Core Graveyard
Profile: Migration
17 years ago
a year ago


(Reporter: Teruko Kobayashi, Unassigned)



Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




17 years ago
Profile migration does not migrate accept language and default charset.

Steps of reproduce
1. Use 4.7 JA build to create Japanese profile
    Accept Language is set to Japanese [ja], and the defaut charset is set to Shift_JIS.
2. Launch Profile Migration from Netscape 6
3. Launch Netscape 6 from the migrated profile
4. Open Preferences dialog
5. Select Navigator-Language in the Preferences dialog
    On the right side for "Languages in order of preferences:" is English [en]

    And, Default Charset Coding is "Western (ISO-8859-1)".

    Expected result
      Language should be set to "Japanese [ja]"
      Default Charset Coding should be set to "Japanese (Shift_JIS)".

Tested 2000-10-14-08 MN6 Mac build and 2000-10-15-08 MN6 Win32 build.


17 years ago
QA Contact: gbush → teruko

Comment 1

17 years ago
As far as I know the migration code doesn't change any prefs relating to default
char-set.  Could you give me the following information:
1. What is the pref and its value that actually gets set when using 4.7?
2. Open the prefs.js file that got migrated and tell me if that pref is there
and if its value had changed.

See what I believe is happening here is that mozilla is ignoring the old pref
and its value.  


17 years ago
Keywords: intl

Comment 2

17 years ago
Changed QA contact to ylong@netscape.com.
QA Contact: teruko → ylong

Comment 3

17 years ago
nominating for nsbeta1.
Keywords: nsbeta1

Comment 4

17 years ago
Minusing this one for nsbeta1. But it should be fixed for RTM.
Keywords: nsbeta1 → nsbeta1-
re-nominating. See mail that says we're using "nsbeta1" to mean "nsfix" 
regardless of which shipment, and the target milestone to indicate when it 
should be done. for example, nsbeta1+ and mozilla0.9.2 is a perfectly 
reasonable state.
Keywords: nsbeta1- → nsbeta1
however, dbragg isn't doing profile migration anymore. Trying racham.
Assignee: dbragg → racham

Comment 7

17 years ago
Marking as Major | P2 | TM = 0.9.2, as migration needs to work smoothly for the 
users this round (e.g. Project Goals).

Vishy - Let's review during i18n triage.
Severity: normal → major
Keywords: nsCatFood
Priority: P3 → P2
Target Milestone: --- → mozilla0.9.2

Comment 8

17 years ago
moving to 0.9.3
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Comment 9

16 years ago
Doesn't look like this is getting fixed before the freeze tonight.
Pushing out a milestone.  Please correct if I'm mistaken.
Target Milestone: mozilla0.9.3 → mozilla0.9.4

Comment 10

16 years ago
moving to 0.9.5.
Target Milestone: mozilla0.9.4 → mozilla0.9.5

Comment 11

16 years ago
moving to 0.9.6

Comment 12

16 years ago
really  moving to 0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6

Comment 13

16 years ago
moving to mozilla1.0
Target Milestone: mozilla0.9.6 → mozilla1.0


16 years ago
Blocks: 104166


16 years ago
Keywords: nsbeta1+


16 years ago
Priority: P2 → P3


16 years ago
Blocks: 122274
Keywords: nsbeta1+ → nsbeta1-
Target Milestone: mozilla1.0 → mozilla1.2
mass re-assign.
Assignee: racham → sspitzer
is this still valid even though it was written against netscape 6?
QA Contact: amyy → profile-migration
sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.
Assignee: sspitzer → nobody
I'm going to assume that after 12 years (and no response to the 2006 inquiry in comment 15), this has been solved somehow. Resolving WFM.
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
Target Milestone: mozilla1.2alpha → ---


a year ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.