Closed
Bug 78566
Opened 23 years ago
Closed 23 years ago
Persist Language Encoding selection in prefs across pref window instantiations
Categories
(Core :: Internationalization, enhancement)
Core
Internationalization
Tracking
()
VERIFIED
FIXED
mozilla0.9.3
People
(Reporter: paulkchen, Assigned: jbetak)
Details
(Keywords: intl, Whiteboard: landing scheduled for 05/17/2001)
Attachments
(1 file)
1. Go to Preferences. 2. Select Appearance->Fonts 3. Changes Language Encoding to something else 4. Click 'OK' button. 5. Go back to preferences, apperance->fonts What should happen: Language Encoding shows new encoding selection. What actually happens Language Encoding shows "old" encoding, i.e. the change of pref didn't happen -- change encoding from western to traditional chinese, go back to prefs, encoding still shows western.
Comment 1•23 years ago
|
||
Is that starting from today's build? Reassign to jbetak.
Assignee: nhotta → jbetak
Keywords: intl
Assignee | ||
Comment 2•23 years ago
|
||
Naoki, I don't think this is a regression. I'll clarify with Paul, but at this point it seems that he would like to persist the last selected language encoding. This would work when switching pref panes, but not for newly initialized pref window and I believe that's, what he is pointing out in this bug. Unless, I understood it incorrectly, it never worked quite this way.
Assignee | ||
Comment 4•23 years ago
|
||
pchen, I tried to talk to you in person this week. I believe this is an enhancement request. Could you please confirm, whether the reported behavior exists in both IE and NS4.x?
Assignee | ||
Comment 5•23 years ago
|
||
pchen: I believe this is an enhacement request. Could you please provide feedback on the discussion in this bug? You keep us guessing...
Sorry I haven't been responsive. Yes, we would like persistance of the last selected encoding. We saw this during navigator triage meeting because of some other bug. If this is the way it's supposed to work, then by all means, mark this bug as invalid.
Assignee | ||
Comment 7•23 years ago
|
||
nhotta: do we still want this as enhancement for 1.0?
Status: NEW → ASSIGNED
Comment 8•23 years ago
|
||
I don't think this is critical. Please change severity to enhancement and milestone to future.
Assignee | ||
Comment 9•23 years ago
|
||
pchen: we'll keep it on our radar as an enhancement request. Thanks for your follow-up...
Severity: major → enhancement
Target Milestone: --- → Future
Reporter | ||
Comment 10•23 years ago
|
||
changing summary to better reflect enhancement
Summary: Changing Language Encoding in prefs doesn't work → Persist Language Encoding selection in prefs across pref window instantiations
Assignee | ||
Comment 11•23 years ago
|
||
Assignee | ||
Comment 12•23 years ago
|
||
pchen, nhotta, I was reviewing some changes for bug 28899 and realized that this bug can be fixed in a very expedient way. Please let me know (r?), what you think of the proposed patch and I'll try to get a sr before Beta1...
Assignee | ||
Updated•23 years ago
|
Target Milestone: Future → mozilla0.9.1
Assignee | ||
Comment 13•23 years ago
|
||
nominating for Beta1, fix in hand
Keywords: nsbeta1
Whiteboard: need r/sr, fix in hand, 05/14/2001 - 22:55:00
Reporter | ||
Comment 14•23 years ago
|
||
well, if that's all it takes, then r=pchen ;-)
Assignee | ||
Comment 15•23 years ago
|
||
alecf, could I pester you with yet another sr request for a miniscule bug fix? FYI: I'm currently exploring ways to fix bugs by adding whitespace ;-)
Comment 16•23 years ago
|
||
that doesn't seem like the right fix - I mean, isn't this a preference? This could get out of sink if the user's localstore.rdf gets lost
Comment 17•23 years ago
|
||
that shoult not be a preference since it does not specify anything. It SELECT the working set of the font. I ask jbetak talk to you face to face to go over this issue.
Assignee | ||
Comment 18•23 years ago
|
||
I'll restate the obvious - just for clarity's sake. The font prefs dialog allows you to maintain an array of values - namely a set of preferred font faces for every language group . There is no such thing as a "Language encoding", this unlucky choice of wording will change with bug 28899 to "Fonts for", which better reflects the meaning and use of this field. There is another pref named "Default Character Coding" in the languages pane, which is probably what the current "Language encoding" was commonly confused with (see original comment from pchen). As ftang said, this enhancement is strictly visual and for convenience only, it merely saves the need to switch from Latin-1 to say Japanese every time you want to change your fonts and happen to browse Japanese web pages most of the time. What do we lose by not having a dedicated pref? Well, we cannot make the Japanese language group to show up by default in the localized Japanese build. I'm still investigating, whether the localized build issue warrants a separate pref for the field, but I'd really like to close or move this bug...
Assignee | ||
Updated•23 years ago
|
Whiteboard: need r/sr, fix in hand, 05/14/2001 - 22:55:00
Comment 20•23 years ago
|
||
ok, I'm still confused then.. is this or is this not a preference? basically my concern is, does someone need to retrieve this value from anywhere else besides the dialog, or is this, as you say, a convenience feature... if it's a convenience feature, then sr=alecf... I may have misunderstood what you were fixing before.
Assignee | ||
Comment 21•23 years ago
|
||
alecf, thanks for still following this arcane discussion! I'll confirm that the "Language Encoding" field is not a preference, it's a selector which enables you to view a group of font face preferences for a particular language. The field label is very unfortunate since it implies that this could potentially be more than what it really is. As already mentioned, the wording will change into something less hideous with the landing of Gerv's patch for bug 28899 - and thank God for that! I checked with nhotta about the localized build issue and he agreed that we can inconvenience international users and expect them to switch the fonts pref view from Latin-1 to whatever language group they are interested in.
Whiteboard: landing scheduled for 05/17/2001
Assignee | ||
Comment 22•23 years ago
|
||
closing - thanks everyone...
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 23•23 years ago
|
||
Fixed verified on 05-21 Windows and Linux trunk build.
Status: RESOLVED → VERIFIED
Comment 24•23 years ago
|
||
I need re-open this bug because this feature now works fine when click on "OK" but not on "Cancel"(checked on 06-11-08 Linux and 0.9.1Ja Windows build). Steps: 1. View | Preferences | Appearance | Fonts, change language to something else, then click "Cancel". 2. Go back View | Preferences | Appearance | Fonts, you will see the language has been marked as the changed language in step 1.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Comment 25•23 years ago
|
||
pdt+ base on 6/11 pdt meeting.
Comment 26•23 years ago
|
||
I accidentally add PDT+ on this. This should not be PDT+
Comment 27•23 years ago
|
||
This should be a moz0.9.3 bug.
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Assignee | ||
Comment 28•23 years ago
|
||
Yuying, could you please close this bug and refile the last comment as a new one? The selector is not a preference value and shouldn't depend on the "OK" and "Cancel" buttons. Since alecf voiced a similar concern and apparently there is still confusion about the meaning of the selector, we *could* morph it into a true preference. This would also make the default selection localizable. Please let me know, how I can help...
Updated•23 years ago
|
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Comment 29•23 years ago
|
||
Change the staus as Fixed, and open another bug 85747.
You need to log in
before you can comment on or make changes to this bug.
Description
•