78566 - Persist Language Encoding selection in prefs across pref window instantiations

Status: VERIFIED FIXED

(Core :: Internationalization, enhancement)

Description

[Paul Chen]

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

[nhottanscp]

Is that starting from today's build?

Reassign to jbetak.

Comment 2

[[e-mail] (away - not reading bugmail)]

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.

Comment 3

[Andreas Becker]

Changing QA contact to [e-mail].

Comment 4

[[e-mail] (away - not reading bugmail)]

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?

Comment 5

[[e-mail] (away - not reading bugmail)]

pchen:

I believe this is an enhacement request. Could you please provide feedback on 
the discussion in this bug? You keep us guessing...

Comment 6

[Paul Chen]

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.

Comment 7

[[e-mail] (away - not reading bugmail)]

nhotta:

do we still want this as enhancement for 1.0?

Comment 8

[nhottanscp]

I don't think this is critical.
Please change severity to enhancement and milestone to future.

Comment 9

[[e-mail] (away - not reading bugmail)]

pchen:

we'll keep it on our radar as an enhancement request. Thanks for your follow-up...

Comment 10

[Paul Chen]

changing summary to better reflect enhancement

Comment 11

[[e-mail] (away - not reading bugmail)]

Attachment: cvs diff -u -w xpfe/components/prefwindow > bug78566.txt

Comment 12

[[e-mail] (away - not reading bugmail)]

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...

Comment 13

[[e-mail] (away - not reading bugmail)]

nominating for Beta1, fix in hand

Comment 14

[Paul Chen]

well, if that's all it takes, then r=pchen ;-)

Comment 15

[[e-mail] (away - not reading bugmail)]

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

[Alec Flett]

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

[Frank Tang]

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.

Comment 18

[[e-mail] (away - not reading bugmail)]

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...

Comment 19

[[e-mail] (away - not reading bugmail)]

moving to 0.92

Comment 20

[Alec Flett]

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.

Comment 21

[[e-mail] (away - not reading bugmail)]

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.

Comment 22

[[e-mail] (away - not reading bugmail)]

closing - thanks everyone...

Comment 23

[Yuying Long]

Fixed verified on 05-21 Windows and Linux trunk build. 

Comment 24

[Yuying Long]

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.  

 

Comment 25

[Frank Tang]

pdt+ base on 6/11 pdt meeting.

Comment 26

[Frank Tang]

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

Comment 27

[Frank Tang]

This should be a moz0.9.3 bug.

Comment 28

[[e-mail] (away - not reading bugmail)]

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...

Comment 29

[Yuying Long]

Change the staus as Fixed, and open another bug 85747.

Comment 30

[Yuying Long]

Verified.