756022 - Unify pref font choices for various Latin script-using languages

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Henri Sivonen (:hsivonen)]

(Not sure if this should be a back end bug or a front end bug. Filing as a back end bug to get this triaged by layout engineers.)

Steps to reproduce:
 1) Use an en-US build.
 2) Under Preferences: Content: Fonts & Colors: Advanced change the font selections for serif and sans-serif fonts (i.e. change them for the default "Western" pref group)
 3) Navigate to http://www.w3.org/TR/CSS21/
 4) Look at the list of editors

Actual results:
Tantek's name is rendered in a font that's different from the font used for the names of the other editors.

Expected results:
Expected Tantek's name to be rendered in the same font as Bert's, Hixie's and Howcome's names.

Additional info:
Bert's name is marked up with lang="nl", Tantek's as lang="tr", Hixie's as lang="en" and Howcome's as lang="no". Our font pref taxonomy was created back in the days when Latin fonts had 8-bit repertoires and there were typically different fonts for Western European, Central European, Baltic and Turkish. nl, en and no are considered "Western" but tr is Turkish and, thus, is governed by a different font pref. These days, the kind of fonts one would reasonably use as the fonts that CSS generic serif and sans-serif map to tend to have glyphs for Western European, Central European, Baltic and Turkish use. More and more, Latin fonts even cover IPA-inspired African glyphs (presumably governed by our "Other languages" pref) and if one were a reader of an African language that uses rare Latin extensions, one would probably be sure to choose a font that has those extensions.

It would make sense for the fonts settings for all Latin uses to be governed by one pref view (at least by default). It's pretty annoying to have to make consistent pref changes for multiple legacy-oriented pref groups in order to get consistent outcomes across all Latin script-using languages.

(It wouldn't hurt to have a UI shortcut for syncing even Greek and Cyrillic with the Latin prefs considering that the size considerations are the same and more and more often the sort of high-quality fonts one would use cover Greek and Cyrillic in addition to Latin.)

Comment 1

[John Daggett (:jtd)]

Depending upon the platform, there's no guarantee that the default font for Latin will have coverage for Cyrillic and Greek.  And the prefs are set so that users whose main script is one or the other can opt for a different default font.

I'm sure there's room to consolidate some of these, the Turkish/Latin case for example.

Comment 2

[Henri Sivonen (:hsivonen)]

(In reply to John Daggett (:jtd) from comment #1)
> Depending upon the platform, there's no guarantee that the default font for
> Latin will have coverage for Cyrillic and Greek.  And the prefs are set so
> that users whose main script is one or the other can opt for a different
> default font.

I didn't mean to suggest taking away the ability to set Cyrillic and Greek fonts separately from the Latin font. However, it would be convenient to have a way to synchronize them in one UI action. But that parenthetical remark was off-topic for this bug anyway.

> I'm sure there's room to consolidate some of these, the Turkish/Latin case
> for example.

If we had a unified pref for all Latin, we could even use it for all *-Latn such as  Romaji tagged as lang="ja-Latn".

Comment 3

[Jonathan Kew [:jfkthame]]

This sounds a lot like what I had in mind with bug 556237.

Comment 4

[Gordon P. Hemsley [:GPHemsley]]

(In reply to Jonathan Kew (:jfkthame) from comment #3)
> This sounds a lot like what I had in mind with bug 556237.

Yes, I agree. And the interface would have to support (or have the ability to support) all 160 or so scripts, not just the common Latn, Cyrl, and Grek ones.

Comment 7

[Henri Sivonen (:hsivonen)]

Bug 192636 comment 17 indicates that this has been a problem for Wikipedia. :-(

Comment 8

[Simon Montagu :smontagu]

Attachment: Patch 1: merge x-baltic with x-western

After writing bug 485179 I decided to put my code where my mouth was and fix this.

Comment 9

[Simon Montagu :smontagu]

Attachment: Patch 2: merge x-central-euro with x-western

Comment 10

[Simon Montagu :smontagu]

Attachment: Patch 3: merge tr with x-western

Note that this patch doesn't touch nsGkAtomList.h, because nsGkAtoms::tr is used elsewhere (as a matter of fact it's used both for the <tr> element and the tr language tag, which seems to me like a bug waiting to happen :( )

Comment 11

[Simon Montagu :smontagu]

In theory I'd like to change "x-western" to "Latn" as well, but that would effectively reset the font pref for anybody who has already set it -- or do we have a way to migrate prefs in that kind of situation?

Comment 12

[Jonathan Kew [:jfkthame]]

I wonder whether you should add one more patch to this series: to change the UI string for font.langGroup.latin1 in fonts.dtd (as displayed in the Font preferences dialog) from "Western" to "Latin", to better reflect the newly-extended scope of the preferences it's referring to. WDYT? We'd want to change the entity name, too, so as to alert localizers.

(Perhaps we'd need to say "Latin script", so as not to mislead people into thinking it's specific to the Latin language.)

Comment 13

[Jonathan Kew [:jfkthame]]

(In reply to Simon Montagu :smontagu from comment #11)
> In theory I'd like to change "x-western" to "Latn" as well, but that would
> effectively reset the font pref for anybody who has already set it -- or do
> we have a way to migrate prefs in that kind of situation?

We could write a fragment of JS code that's executed on first run after an update, and moves the old prefs to their new names - e.g. see function BG__migrateUI() in components/nsBrowserGlue.js.

Not sure whether it's worth it here, or if we should just leave this as a somewhat obsolete internal name that normal users won't see.

Comment 14

[Jonathan Kew [:jfkthame]]

> BG__migrateUI() in components/nsBrowserGlue.js.

sorry, that's  browser/components/nsBrowserGlue.js

Comment 15

[Gordon P. Hemsley [:GPHemsley]]

(In reply to Jonathan Kew (:jfkthame) from comment #12)
> I wonder whether you should add one more patch to this series: to change the
> UI string for font.langGroup.latin1 in fonts.dtd (as displayed in the Font
> preferences dialog) from "Western" to "Latin", to better reflect the
> newly-extended scope of the preferences it's referring to. WDYT? We'd want
> to change the entity name, too, so as to alert localizers.

Yes, I agree. The list is primarily of scripts now (with a few language holdouts), and "Western" is not a script (nor is it a language, for that matter).

> (Perhaps we'd need to say "Latin script", so as not to mislead people into
> thinking it's specific to the Latin language.)

We don't do that for, e.g., Arabic, do we? I don't think it'll confuse too many people.

(In reply to Simon Montagu :smontagu from comment #11)
> In theory I'd like to change "x-western" to "Latn" as well, but that would
> effectively reset the font pref for anybody who has already set it -- or do
> we have a way to migrate prefs in that kind of situation?

We'll already be resetting the font pref for anyone who cares about 'x-baltic', 'x-central-euro', or 'tr', so I think we could take the hit on 'x-western', as well. (Are the defaults any different among them?)

Comment 16

[Jonathan Kew [:jfkthame]]

Comment on attachment 8463967 [details] [diff] [review]
Patch 1: merge x-baltic with x-western

Review of attachment 8463967 [details] [diff] [review]:
-----------------------------------------------------------------

::: gfx/thebes/nsUnicodeRange.cpp
@@ +41,5 @@
>  };
>  
>  /**********************************************************************
>   * Unicode subranges as defined in unicode 3.0
> + * x-western, x-central-euro, tr  -> latin 

Please drop the trailing space while you're touching this.

Comment 17

[Henri Sivonen (:hsivonen)]

I suggest also:
 1) Removing the comment about Vietnamese in https://mxr.mozilla.org/mozilla-central/source/intl/locale/langGroups.properties#186 . Clearly, we aren't going to introduce a language group for Vietnamese at this point.
 2) Changing the UI string in the pref pane from "Western" to "Latin".

Comment 18

[Simon Montagu :smontagu]

(In reply to Henri Sivonen (:hsivonen) from comment #17)
> I suggest also:
>  1) Removing the comment about Vietnamese in
> https://mxr.mozilla.org/mozilla-central/source/intl/locale/langGroups.
> properties#186 . Clearly, we aren't going to introduce a language group for
> Vietnamese at this point.

Yes, thanks for the pointer, there are quite a few comments in langGroups.properties that have become irrelevant and can be removed.

>  2) Changing the UI string in the pref pane from "Western" to "Latin".

There seems to be a consensus on this. Personally I'm not sure how clear "Latin" will be to users. What does everybody think about "Roman" as an alternative?

Most other browsers don't seem to have an equivalent of this pref pane. IE has "Latin based" as one option; I'm not sure which languages it covers.

Comment 19

[Jonathan Kew [:jfkthame]]

(In reply to Simon Montagu :smontagu from comment #18)
> >  2) Changing the UI string in the pref pane from "Western" to "Latin".
> 
> There seems to be a consensus on this. Personally I'm not sure how clear
> "Latin" will be to users. What does everybody think about "Roman" as an
> alternative?

I'm a bit concerned about this, too, although I do think we need to change it from "Western" to something that better reflects the extended scope of the setting.

IMO, "Latin [script/alphabet/based]" is probably better than "Roman [ditto]", which I think is a less widely recognized term; it's known from font names like "Times New Roman", of course, but that's perceived as part of the name of the typeface design rather than of the writing system it's implementing.

(FWIW, I notice that wikipedia's article is titled "Latin script"; looking up "Roman script" redirects there.)

Comment 20

[Gordon P. Hemsley [:GPHemsley]]

(In reply to Simon Montagu :smontagu from comment #18)
> >  2) Changing the UI string in the pref pane from "Western" to "Latin".
> 
> There seems to be a consensus on this. Personally I'm not sure how clear
> "Latin" will be to users. What does everybody think about "Roman" as an
> alternative?

I still think unadorned "Latin" is the best, as that is the standard name of the script and no other scripts have a disambiguator attached, even if they might otherwise potentially benefit from one.

(In reply to Jonathan Kew (:jfkthame) from comment #19)
> I'm a bit concerned about this, too, although I do think we need to change
> it from "Western" to something that better reflects the extended scope of
> the setting.
> 
> IMO, "Latin [script/alphabet/based]" is probably better than "Roman
> [ditto]", which I think is a less widely recognized term; it's known from
> font names like "Times New Roman", of course, but that's perceived as part
> of the name of the typeface design rather than of the writing system it's
> implementing.

I actually think "Roman" is the more recognized of the two; but I am not in favor of using it, as that is not the standard name.

The menu contains other strings that refer to scripts and not languages (even though they share a name with one)—e.g. Arabic, Hebrew—but we don't modify them to include "script". I really think the audience for this is small enough as it is.

> (FWIW, I notice that wikipedia's article is titled "Latin script"; looking
> up "Roman script" redirects there.)

Yeah, but Wikipedia has standardized article titles to "X script" and "Y language", so I'm not sure that's the best metric to use.

Comment 21

[Henri Sivonen (:hsivonen)]

AFAICT, the convention is to use "Roman" when referring to numbers (of the "MMXIV" type) and "Latin" when referring to letters.

I can't think of any succinct (fitting in the UI label) way to help people who are insufficiently educated to realize that this sort of letters that their language is written with are called "Latin" letters beyond
 1) making sure that "Latin" is preselected when opening the UI in a browser whose UI locale uses the Latin script.
 2) changing the "Other Languages" label to "Other writing systems" to avoid suggesting that the items in the menu are *languages*, since the items are actually *scripts* aka. "writing systems".

So I think the en-US UI string should be simply "Latin", since it's the right adjective to be in the same category as Cyrillic and Devanagari.

Comment 22

[Simon Montagu :smontagu]

Attachment: patch 4: change "Western" to "Latin" and "Other Languages" to "Other Writing Systems" in the font preferences dialog

Comment 24

[Simon Montagu :smontagu]

Attachment: patch 5: delete obsoleted comments in langGroups.properties and assign x-western to a few unassigned languages that use Latin script

I thought this was going to be a comment-only change, but I ended up uncommenting a couple of language assignments as well

Comment 25

[Jonathan Kew [:jfkthame]]

Comment on attachment 8466912 [details] [diff] [review]
patch 4: change "Western" to "Latin" and "Other Languages" to "Other Writing Systems" in the font preferences dialog

Review of attachment 8466912 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/components/preferences/fonts.xul
@@ +70,5 @@
>              <menuitem value="x-telu"          label="&font.langGroup.telugu;"/>
>              <menuitem value="th"              label="&font.langGroup.thai;"/>
>              <menuitem value="x-tibt"          label="&font.langGroup.tibetan;"/>
>              <menuitem value="x-cans"          label="&font.langGroup.canadian;"/>
> +            <menuitem value="x-western"       label="&font.langGroup.latin;"/>

Now that we're calling this "Latin" rather than "Western", it should move up to come between Korean and Malayalam in the list.

Comment 26

[Jonathan Kew [:jfkthame]]

Comment on attachment 8466915 [details] [diff] [review]
patch 5: delete obsoleted comments in langGroups.properties and assign x-western to a few unassigned languages that use Latin script

Review of attachment 8466915 [details] [diff] [review]:
-----------------------------------------------------------------

Looks fine to me.

What about s/x-western/x-latn/g or something like that, or is it not worth the disruption?

Comment 27

[Henri Sivonen (:hsivonen)]

(In reply to Simon Montagu :smontagu from comment #24)
> I thought this was going to be a comment-only change, but I ended up
> uncommenting a couple of language assignments as well

Nice. Filed bug 1048153 as a follow-up.

Comment 28

[Simon Montagu :smontagu]

(In reply to Jonathan Kew (:jfkthame) from comment #25)
> Comment on attachment 8466912 [details] [diff] [review]
> > +            <menuitem value="x-western"       label="&font.langGroup.latin;"/>
> 
> Now that we're calling this "Latin" rather than "Western", it should move up
> to come between Korean and Malayalam in the list.

Oops, I thought that we sorted the list on the fly -- I've now reopened bug 54746.

Comment 29

[Simon Montagu :smontagu]

Attachment: patch 4: change "Western" to "Latin" and "Other Languages" to "Other Writing Systems" in the font preferences dialog

Comment 30

[Simon Montagu :smontagu]

https://hg.mozilla.org/integration/mozilla-inbound/rev/3d88e3845d62
https://hg.mozilla.org/integration/mozilla-inbound/rev/0b923ab187d3
https://hg.mozilla.org/integration/mozilla-inbound/rev/f0ae82398d23
https://hg.mozilla.org/integration/mozilla-inbound/rev/2a9dfb605be4
https://hg.mozilla.org/integration/mozilla-inbound/rev/13b41d588e0c

Comment 31

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/f0ae82398d23
https://hg.mozilla.org/mozilla-central/rev/2a9dfb605be4
https://hg.mozilla.org/mozilla-central/rev/13b41d588e0c

Comment 32

[Jonathan Kew [:jfkthame]]

Also these two changesets, which landed with an incorrect bug number (750622):
> https://hg.mozilla.org/mozilla-central/rev/3d88e3845d62
> https://hg.mozilla.org/mozilla-central/rev/0b923ab187d3

Comment 33

[Gordon P. Hemsley [:GPHemsley]]

(In reply to Jonathan Kew (:jfkthame) from comment #26)
> What about s/x-western/x-latn/g or something like that, or is it not worth
> the disruption?

If we're gonna change it, we might as well go full 'Latn' (or at least 'latn').

(See also bug 1048153 comment 1.)