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)

Product:
Core
Component:
Internationalization
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.3

People

(Reporter: paulkchen, Assigned: jbetak)

Details

(Keywords: intl, Whiteboard: landing scheduled for 05/17/2001)

Attachments

(1 file)

cvs diff -u -w xpfe/components/prefwindow > bug78566.txt
1.05 KB, patch
Details | Diff | Splinter Review 
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.
Is that starting from today's build?

Reassign to jbetak.
Assignee: nhotta → jbetak
Keywords: intl
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.
Changing QA contact to ylong@netscape.com.
QA Contact: andreasb → ylong
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?
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.

nhotta:

do we still want this as enhancement for 1.0?
Status: NEW → ASSIGNED
I don't think this is critical.
Please change severity to enhancement and milestone to future.

pchen:

we'll keep it on our radar as an enhancement request. Thanks for your follow-up...
Severity: major → enhancement
Target Milestone: --- → Future
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
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...
Target Milestone: Future → mozilla0.9.1
nominating for Beta1, fix in hand
Keywords: nsbeta1
Whiteboard: need r/sr, fix in hand, 05/14/2001 - 22:55:00
well, if that's all it takes, then r=pchen ;-)
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 ;-)
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
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.
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...
moving to 0.92
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Whiteboard: need r/sr, fix in hand, 05/14/2001 - 22:55:00
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.
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
closing - thanks everyone...
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Fixed verified on 05-21 Windows and Linux trunk build.
Status: RESOLVED → VERIFIED
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 → ---
pdt+ base on 6/11 pdt meeting.

I accidentally add PDT+ on this. This should not be PDT+

This should be a moz0.9.3 bug.
Target Milestone: mozilla0.9.2 → mozilla0.9.3
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...
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Change the staus as Fixed, and open another bug 85747.
Verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: