In T73240#1351659, @ori wrote:

In T73240#1351242, @Tgr wrote:

I think a way to manage language-specific CSS tweaks in source code should be the first step.

Sounds good. Is there a task for this, and if not, could you create one?

T101936

In T73240#1351765, @ori wrote:

• @Isarra indicated (on Gerrit) that she would want to re-work her patch before looking to have it merged.

Different task-related change. That was the one about the h5-6 being the same (T72004), among other things, but how that one would look would probably depend on this one (also I think I may have crammed too much into one patch there): https://gerrit.wikimedia.org/r/#/c/164712/

@Tgr (re-)articulated a plan to approach this from another angle.

T101936 is good but nothing new, we've had patches open for months and there is no bandwidth to review them, so we're back to problems of unmaintained-ness. If someone wants to send a patch to restore the traditional font stack by default, while keeping the current one for the "en" locale, I think that would be a first step in the right direction as well.

Regarding the visual hierarchy issues on Linux with the current stack, it is an issue worth considering but it can be solved in different ways:

• Increase the font size for H1 and H2. Currently our font sizes fall in the "small" spectrum of what is considered in most readability guidelines for text on the web. I'd not discard the option to increase H1 and H2 assuming it will be "too big" in some platforms before actually checking it.
• Adjust the font stack to avoid the size discrepancies across platforms. This can mean using the same font across all headings or find a replacement for Georgia that is more compatible in size with the default fonts provided on each platform for generic font families.
• Modify the current H3-6 heading styles. For the sake of exploring possibilities we can also consider reducing the font size for H3-6 or using the same serif stack on all headings.

In any case, I think this issue is worth exploring before jumping at one particular direction (e.g., default to the standard "sans-serif" generic family) in order to identify the effects of the change. For example, using a different font for the main headings is also a way to provide contrast that may help to easily identify them. That would get lost if the current patchset gets merged.

Regarding non-latin script support, even with webfont support it would be hard to find a font family that consistently supports all languages. When recommending local fonts to the browser (what we do with the current font stacks), you need to either rely on generic families (e.g., sans-serif or serif) as it happens now, or define specific font stacks for those languages where the defaults can be improved. It is possible to create language-specific rules that provide stacks that are better suited for them. Those specific adjustments can be part of the core style to avoid the need for individual communities to override them.

@Quiddity
I emulated your conditions on a browser and what you are saying makes sense. the hierarchy is not right but that is an issue of bad pairing. Your sans typeface is Deja Vu. Deja Vu Bold's weight is as much as any other heavy sans. That's why there is much contrast between linux libertine and deja vu. Everyone can have their own sans fonts and it's just impossible find a serif that pairs well with every one of them. I don't think changing font style for "everyone" to solve this problem is a good way.
Also, i tried the patch has and it emphasizes your headings very subtly. It's not going to solve the issue entirely, as i said the weight of Deja Vu Bold is the problem.

@Legoktm Jorm also said this -

Let's not forget that individual wikis can (and should) adjust font weights and styles based on their own need in Common.css. This is particularly true for wikis that use non-Latin scripts (Typography refresh is particularly bothersome in Vietnamese, for instance).
I'm not sure its possible for us to build a "one size fits all" model.

^ Which I totally agree. There are different languages and different scripts, finding this one perfect solution is not realistic. you have to design for all cases. Also, disregarding T101936 as a viable option here sounds bit hasty.
As @Pginer-WMF articulated it.

In T73240#1354410, @Nirzar wrote:

There are different languages and different scripts, finding this one perfect solution is not realistic. you have to design for all cases. Also, disregarding T101936 as a viable option here sounds bit hasty.

T101936 is probably exactly where we want to go in the long run, since especially Wikimedia kind of needs that. The problem is for now, things are broken because when the change was initially done, the infrastructure simply wasn't ready. Will it be ready any time soon?

Change 217707 had a related patch set uploaded (by Nirzar):
Make headers use sans-serif for non latin script

https://gerrit.wikimedia.org/r/217707

The problem is for now, things are broken because when the change was initially done

I agree!

As @Volker_E has suggested

or styles and as handler for JS we're already able to use :lang pseudo-class (IE8+) or attribute selectors like [lang="en"] or [dir="ltr] (IE 7+) to target different languages.
Changing a theme based on language would be a subtask, but varying the skin is already supported by those selectors. It's the best approach out there says the W3C.

here's another solution,
I tested this on local mediawiki and it works. This is more scalable solution than local overrides because this will work for new mediawiki installs too.

Questions about this solution!

Doesn't it look like hardcoding the values?
Also, if it seems like hardcoding things but these are not variables. It's based on the assumption that Japanese and other non latin languages will always be non latin. I think it's a fair assumption. we can populate this list if other languages are having any issue.

why should everyone carry the weight of language specification?
The weight of this (~84 bytes) is far less than the value it provides.

Is there more semantic way of doing this?
Yes, but that requires latest version of less compiler.
here's a way of doing it - writing an array and running through a for loop

// Array for non latin languages
@non-latin-languages: ja, he, ko;

.createLanguageSpec (@i:0) when (@i:length(@non-latin-languages)) {

	@code : extract(@non-latin-languages,@i); 
		body:lang(@code) {
			.mw-body h1, .mw-body h2 {
				 font-family: sans-serif;
		}
	}
	@i: @i++;
}

.createLanguageSpec();

// there might be a syntax error but you get the idea.

How will people know about this?
This will be included in documentation of typography refresh thread and FAQ threads of the wiki pages.

This doesn resolve the issues in english/other latin scripts.

This doesn resolve the issues in english/other latin scripts.

All the bugs mentioned in your patch are about non-latin scripts.

Issues in english are not breaking things, are they?

Things do not need to be explicitly broken to be problematic or merit
improvement. If they did, there would never have been grounds for the
typography refresh in the first place, nobody would be trying to keep
any of it now, and we would not be having this conversation.

This doesn resolve the issues in english/other latin scripts.

The inconsistent heading sizes on platforms where Georgia is missing, seems solvable by increasing H1 and H2 font sizes (or at least is an option worth exploring and comparing with the proposed approach in the patchset). Are there any other issues on latin script languages we need to explore solutions for?

In T73240#1359076, @Isarra wrote:

This doesn resolve the issues in english/other latin scripts.

It would generally help to have clear descriptions of those issues. The bugs mentioned so far mostly link to discussions and images which have since been removed; even the few which don't are unclear. E.g. the Japanese issue seems to be about the mixing of Mincho and Batang fonts, neither of which appear in the typography refresh. (It also links to an IE10 bug report in Japanese which is probably not super helpful to most participants of this discussion.) File:Typography refresh - Times new roman header - new-vers.png supposedly shows a bug about a Times New Roman header appearing on he.wiki, but I am unable to find anything like that on the screenshot (there is an annotation but it just further confuses things).

FWIW Japanese, Russian and Chinese are 7%, 5% and 3% of the total pageviews respectively (all other non-Latin scripts are below 1%, though probably still a high share cumulatively). Obtaining more feedback about those languages would be a good next step.

In T73240#1361394, @Tgr wrote:

FWIW Japanese, Russian and Chinese are 7%, 5% and 3% of the total pageviews respectively (all other non-Latin scripts are below 1%, though probably still a high share cumulatively). Obtaining more feedback about those languages would be a good next step.

At the time of launch, IIRC the feedback was that in Russian the serifs were fine, but in Japanese, Korean, and Chinese this older style of font (https://en.wikipedia.org/wiki/Serif#East_Asian_analogues) is way less common on modern websites. I think it would be appropriate to create language-specific overrrides for these three scripts, and I encouraged site admins there to do so locally if they desired.

Reasons for the serif headers seem to be:

• Some people like them more
• Better contrast between text and headers
• Matching the MobileFrontend design, which also uses serif headers, in order to make the cross-platform experience more consistent
• Matching the text style in the Wikipedia logo, which uses the Linux Libertine font (only works if Linux Libertine is actually installed on the system)
• They have been deployed for a few months, at least on Wikimedia projects
• Anything else?

Current issues with the serifs, less i18n issues, include the following:

• Some people don't like them
• Scanability issues caused by the lack of contrast between headers and content due to the relative lightness of h1s and h2s (especially Georgia), especially when compared to bold sans-serif h3s
• Scanability issues due to h3s standing out more than h1s and h2s due to relative sizes and weights of used fonts (the bold sans-serif fonts can appear larger than non-bold serifs, especially the relatively small Linux Libertine and Times New Roman)
• Inconsistent font stack results in a different experience depending on platform (Georgia doesn't really match any of the others)
• Don't match the text style in logos for projects such as Commons, Wikivoyage, Wikinews, MediaWiki, Wikidata, Wikiquote, and others
• Still don't necessarily match the text style of the Wikipedia logo (Georgia on windows; georgia on osx isn't nearly as bad as at least the weight is still similar)
• Unexpected/unwanted ligatures showing up in headers (especially when using the Georgia font), causing problems with page title display

Here's the thing, though. I didn't include i18n isses, but if we're solving the i18n issues by simply removing the styles for other scripts, what is the justification for actually keeping them for the latin scripts? If it's not worth maintaining some fashion of fancy header with the others, why is it with these, and why do these take such priority over the others?

That seems wrong.

@stevenwalling I wonder if it would make more sense to use a mixed stack, like Facebook does, e.g. "Linux Libertine", Georgia, sans-serif. That behaves identically on all wikis (e.g. romaji text on jawiki would look the same as enwiki), and is not problematic (at least no more than the pre-typography-refresh defaults) on Linux and non-Latin wikis.

Unexpected/unwanted ligatures showing up in headers (especially when using the Georgia font), causing problems with page title display

That was mentioned a few times, but never with a concrete example; can your provide one? It would probably deserve its own ticket.

It would probably deserve its own ticket.

...which could then be ignored for a few more years.

Not having the affected font(s) nor any idea where the discussion was that brought this up, I don't have any examples, no. Unfortunately most of the issues were simply ignored at the time, even despite some engagement from the team involved, so a lot of what would have been easily actionable was simply lost.

Change 220610 had a related patch set uploaded (by Gergő Tisza):
Change fallback heading font to sans-serif

https://gerrit.wikimedia.org/r/220610

WMF is caring with several people involved about getting different problems from this task being improved/resolved. Already published changes 217707 and 220610 are both addressing the issues with the serif headers in non-latin languages like Hebrew, Japanese and Korean with two approaches.

In T73240#1398123, @Volker_E wrote:

WMF is caring with several people involved about getting different problems from this task being improved/resolved. Already published changes 217707 and 220610 are both addressing the issues with the serif headers in non-latin languages like Hebrew, Japanese and Korean with two approaches.

These are great. Thank you to everyone pushing/reviewing those.

(This comment is more for Gerrit patchset 220610 I guess, but I don't have an account there.)

Hi, not sure if people have already discussed it, but with Windows 10 there is now for-free access to the Georgia Pro font family, which has better international support and uppercase figures by default. Shouldn't that be added to the font stack list, before Georgia?

@Fito: Do you have any idea if Windows 10 automatically uses Georgia Pro as a fallback for Georgia. It should be fairly easy to test if you have Windows 10. If so, we wouldn't need to change anything. If not, I agree that we may want to add that as an explicit font in the stack.

It looks like Georgia Pro is in a Pan European Set which can be installed from optional features in Settings on Windows 10

@kaldari: No, I don't think Windows 10 implements anything like automatic font substitution. Georgia Pro is not even installed by default (in order to save space), but you can easily get that (along other updated families) by going to Settings and selecting the "Pan-European Supplemental Fonts" package.

EDIT: @Vibhabamba is right, I was writing this comment when she beat me to it =)

There is no automatic font substitution in Windows AFAIK (ie. when a font is not available, instead of proceeding on the next item on the CSS font stack, a system with font substitution would use some kind of internal rules to try and find a font that looks similar and pretend that it is the same font - fontconfig does that on Linux, for example).

I am less sure that there isn't any glyph fallback (ie. when a font is present but it does not provide a glyph for a specific character, a glyph from another font is used instead). That's an application-level thing, it's a fairly fundamental feature for modern browsers, and IE has been pretty good lately in catching up on fundamental features, so I would be surprised if IE 10 and 11 had no glyph fallback. It's not so easy to test though, as glyph fallback might work differently for different codepoint ranges.

At any rate, I don't see any harm in prepending Georgia Pro - it's the same visually, supports a superset of fonts and it is supposed to have small improvements like better kerning and more ligatures.

We should not specify fonts that are marginally installed by default. Some time back, enwiki had a font stack for unicode fonts that included 30(!) fonts. It grew over the years because each time some glyph didn't work, another font was added. I ended up removing it as it started to interfere with the browser's glyph fallback. So let's not fall into that trap, lest we end up with 30 fonts.

Besides, I don't like Georgia that much anyway. I'm using Times for headers, and when properly sized, does not look at all that different from Georgia.

@Edokter would you point me to that state (to a revision) back then out of curiosity? Thx.

@Volker_E, You mean the font stack? Last revision is here, it then moved to a separate CSS page before it was killed off. Now, Common.js only loads two common Unicode fonts, and only on XP.

In T73240#1531813, @Edokter wrote:

Some time back, enwiki had a font stack for unicode fonts that included 30(!) fonts. It grew over the years because each time some glyph didn't work, another font was added. I ended up removing it as it started to interfere with the browser's glyph fallback. So let's not fall into that trap, lest we end up with 30 fonts.

So if I understand correctly the problem with that was that the font stack overrode the browser's own glyph fallback and it ended up using glyphs from random elements of the CSS stack while with a shorter stack it would have picked superior glyphs.

That clearly doesn't apply here: Georgia Pro is a superset of Georgia so there isn't any situation where glyph fallback would be adversely influenced by sticking it at the font of the stack. So I don't really understand your objection (apart from the part where you don't like Georgia :).

Collecting font support metrics seems a good start to evaluating this.

Change 217707 merged by jenkins-bot:
Allow an alternate, generic header font to be specified for certain languages

https://gerrit.wikimedia.org/r/217707

Verified fix on http://en.wikipedia.beta.wmflabs.org/wiki/%E3%82%A2%E3%83%AB%EF%BC%9D%E3%83%9E%E3%82%B0%E3%82%BF%E3%82%B9

Anything actionable left to be done here?

While this is just about general 'this stack good/bad?', that patch was solving some of the more concrete i18n problems, so if anyone wants to go find any of the tasks for those and check them, that would be quite useful. Not that they were ever terribly well categorised and connected, or stuff.

Change 216028 abandoned by Isarra:
Make headers use the same fonts as the rest of the content

https://gerrit.wikimedia.org/r/216028

@Jdlrobson Your link on the Beta Cluster is a bit confusing: the lang of the heading in your example on the Beta Cluster is en. Or did this change over the last couple of months and it was ko before?

https://ko.wikipedia.beta.wmflabs.org/wiki/%E3%82%A2%E3%83%AB%EF%BC%9D%E3%83%9E%E3%82%B0%E3%82%BF%E3%82%B9 seems to be a better example of the outcome.

Change 220610 abandoned by Krinkle:
Change fallback heading font to sans-serif

Reason:
Closing due to inactivity. See T73240 for further discussion. Seems like we don't yet have consensus to evaluate a potential patch.

https://gerrit.wikimedia.org/r/220610

Continued in context of the Desktop Improvements project: T243508: Suggestion: Enable the user to choose up-to-date fonts, more legible on LCD screens