Page MenuHomePhabricator

Re-evaluate serif font stack for headers
Open, NormalPublic

Description

In vector, the h1 and h2 use serif fonts (everything else is sans-serif). Unfortunately the font stack used results in a highly inconsistent user experience across different browsers, due to also affecting the visibility and or relative sizes of the headers.

The stack is thus: @content-heading-font-family: "Linux Libertine", Georgia, Times, serif;

Linux Libertine: Ideal font according to the current design. Relatively small, heavy serif font. Installed by default on pretty much no platforms.

Georgia: Relatively large, light serif font, when compared to Linux Libertine. Incompatible with some languages, also results in legibility issues due to strange rules for some character combinations. Installed by default on windows and mac(?).

Times: Somewhat generic fallback. Tries to go for a 'times' style serif or something. No different effect than 'serif' on most platforms.

serif: Generic fallback. Results in any number of different fonts, from DejaVu serif (which is downright ugly especially at larger sizes) to Times New Roman (which is smaller and lighter than Georgia).

Headers need to stand out in order to be effective, and the relative small sizes and lightness of some of these, especially when combined with relatively large sans-serif fonts in other headers/content text, limits this effectiveness on some platforms.

If the font delivered could be standardised (probably to the default, Linux Libertine), this could help to address many of the inconsistency issues. However, if core support for webfonts is not yet sufficient to handle this, is this font stack really appropriate at present given its inherent instability?


Version: 1.24+
See Also:
T65817Provide a workaround to IE's bug that causes the generic "serif" rendered broken (Japanese)
T71998Vector: h3 should not appear as heavier weight than h2
T72004h4, h5, and h6 headers should not have the same styling
T101936Allow styles to be language-dependent

Details

Reference
bz71240

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

@stevenwalling Please read what we said.

@Edokter Enough, please. Simple misunderstandings do not merit belittlement and general incivility. We have had too much of that already.

Anyway...

In T73240#1351193, @Tgr wrote:

We are talking here about site CSS, though. At any rate, those CSS rules are already there so the cost to add them has already been paid and the cost to remove them once there is a central solution will have to be paid no matter what, so their only impact is the effort to maintain them, which is as far as I can see pretty much zero.

Adding css to a new wiki is not zero effort. Updating it when core rules change is not zero effort; even just finding out that the rules changed can be difficult, and MediaWiki.css in general is a page that is incredibly difficult to maintain, prone to accumulating soup over years that nobody quite knows where it came from (just look at enwp's, and that's a project with a lot of folks on it who could maintain it). Removing it when core support is added is not zero effort, and indeed can take years to actually happen.

Now consider that Vector is the default MediaWiki skin. Consider that thousands of websites, perhaps more, use MediaWiki. Consider that more are being set up all the time, and some of those are in the affected language. Consider how it reflects the entire software when the installer has messed up or even broken fonts. Consider how it might be for a new sysadmin to first find out what the problem even is, and then manually add in the code to fix it. And every single one would have to do this, for every wiki, time and again. Redundant effort.

That's not reasonable. It's not for one wiki that Jorm's line is so important. It's for all of them.

Tgr added a comment.Jun 10 2015, 12:04 AM

@Isarra I sympathize but we are talking about a cost that has already been paid. Changing the stack now will not help it; if anything, it will make it worse since all those wikis will have to be updated, and if this change is not based on a solid consensus and does not last long, then updated again and again... I think a way to manage language-specific CSS tweaks in source code should be the first step.

There has been time, and time aplenty, for more graceful fixes, but those haven't happened. Don't try to block this because they could still happen.

In T73240#1351242, @Tgr wrote:

@Isarra I sympathize but we are talking about a cost that has already been paid. Changing the stack now will not help it; if anything, it will make it worse since all those wikis will have to be updated...

Uh... what? No. That's ridiculous. By that logic we shouldn't have ever fixed any i18n bugs that already had local fixes on some sites.

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

It would be nice, but in the months since the release of these changes initially, this still hasn't happened. Blocking concrete fixes on maybes has gone on long enough.

Jorm added a subscriber: Jorm.Jun 10 2015, 5:06 AM

I think we should just revert back entirely to "sans-serif" and move forward with that. I don't think that the switch to Serif for headers had any real logic behind it other than "let's try something different" which is never a great reason to do anything. If there were actual research - numbers, say, or a study - anywhere that said otherwise, I might rethink that opinion. Since (as has been argued endlessly) defining specific fonts creates insane degrees of problem with internationalization, moving towards the generic makes sense.

Anyways: Reverting to sans-serif with appropriate weights and treatments for headers would be my favored course of action.

Since (as has been argued endlessly) defining specific fonts creates insane degrees of problem with internationalization, moving towards the generic makes sense.

Exactly. That's why every major well-internationalized website uses no specific font stack declarations whatsoever. </sarcasm>

Jorm added a comment.Jun 10 2015, 5:40 AM

Which ones are those? I'm serious. Are there examples of software designed for use on 250+ languages that we can learn from? Or are we blazing trail here?

ori added a comment.Jun 10 2015, 5:47 AM
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?

the practical impact for those languages is that wiki administrators need to maintain local CSS overrides (which does not seem like a huge cost).

As far as I know, the locales you mentioned have not yet been deprecated as MediaWiki locales. As long as we claim to support those locales, the need for MediaWiki core defaults to work with them trumps EVERYTHING else.

Which ones are those? I'm serious. Are there examples of software designed for use on 250+ languages that we can learn from? Or are we blazing trail here?

Ignoring the fact that many of these "250" are dead wikis without much content or readers to design for (https://wikimania2014.wikimedia.org/wiki/Submissions/Wikistats:_New_Patterns), it's already acknowledged that there is no such thing as one font stack for every possible script. What the default font declarations are about is setting reasonable defaults for the vast majority of users.

Jorm added a comment.Jun 10 2015, 6:21 AM

I'm confused. Are you arguing for or against my position?

ori changed the task status from Open to Stalled.Jun 10 2015, 6:29 AM

Closing for now because:

  • @Isarra indicated (on Gerrit) that she would want to re-work her patch before looking to have it merged.
  • @kaldari has identified three discrete bugs that are lumped together in this task and that ought to be disaggregated.
  • @Tgr (re-)articulated a plan to approach this from another angle.
  • The signal-to-noise on this task ratio is low.
Nirzar added a subscriber: Nirzar.Jun 10 2015, 6:32 AM

@ori

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

I think @Jdlrobson has mentioned something similar with his patch https://gerrit.wikimedia.org/r/#/c/125760/

Tgr added a comment.Jun 10 2015, 6:36 AM

Which ones are those? I'm serious. Are there examples of software designed for use on 250+ languages that we can learn from? Or are we blazing trail here?

Facebook for example uses Georgia, 'lucida grande', tahoma, verdana, arial, sans-serif for the link titles. Could be localization-dependent, I didn't check; it could also be that they just don't care as much as we do (although they have a much larger userbase and more engineers to throw at it) but it's still not something I would dismiss off-hand.

Jorm added a comment.Jun 10 2015, 6:41 AM
In T73240#1351793, @Tgr wrote:

Facebook for example uses Georgia, 'lucida grande', tahoma, verdana, arial, sans-serif for the link titles. Could be localization-dependent, I didn't check; it could also be that they just don't care as much as we do (although they have a much larger userbase and more engineers to throw at it) but it's still not something I would dismiss off-hand.

And if you set your browser language to Tamil or are located in the Tamil region, what happens? Do we _know_ or are we _guessing_? Are we just saying "I love this font and fuck everyone else" or is there a serious argument that can be made "we are bettering the encyclopedia"? If there isn't an argument for that, let's just call this a vanity thing and move on towards producing the best, most freely available work of data.

In T73240#1351765, @ori wrote:

Closing for now because:

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

I see no evidence of this in Gerrit. Isarra has left a number of insightful and patient comments both here and on Gerrit that make a compelling argument for reverting this change. What are you referring to when you suggest that the proposed changeset isn't ready to be merged?

  • @kaldari has identified three discrete bugs that are lumped together in this task and that ought to be disaggregated.

That's irrelevant. If you or Kaldari want to file separate tasks for other work, go ahead.

I'm strongly inclined to re-open this task.

Tgr added a comment.Jun 10 2015, 7:39 AM

And if you set your browser language to Tamil or are located in the Tamil region, what happens? Do we _know_ or are we _guessing_?

I would say we are doing research, which is somewhere between the two :) I set the browser language to Tamil, set my Facebook language to Tamil and looked for a post which links to a website written in Tamil; the font stack is the same. (I didn't bother finding a proxy, but I can do that if you strongly believe it would change the outcome.)

Are we just saying "I love this font and fuck everyone else" or is there a serious argument that can be made "we are bettering the encyclopedia"?

I honestly have no romantic feelings whatsoever towards Georgia, I just feel the seriousness of the pro arguments should be measured against the seriousness of the contra arguments. I do not want to trivialize the reports about Linux and non-Latin problems, but some of the claims are clearly exaggerated.

Tgr added a comment.Jun 10 2015, 7:41 AM
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

Isarra added a comment.EditedJun 10 2015, 1:19 PM
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/

MZMcBride changed the task status from Stalled to Open.Jun 10 2015, 2:26 PM

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

Isarra claimed this task.Jun 11 2015, 1:18 PM
Isarra raised the priority of this task from Low to Normal.
Isarra updated the task description. (Show Details)
Isarra added a subscriber: ashley.

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

Nirzar added a comment.EditedJun 11 2015, 9:26 PM

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?

Volker_E updated the task description. (Show Details)Jun 12 2015, 1:56 PM
Volker_E updated the task description. (Show Details)Jun 12 2015, 3:02 PM
Tgr added a comment.EditedJun 12 2015, 7:17 PM

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.

stevenwalling added a comment.EditedJun 12 2015, 11:36 PM
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.

Isarra added a comment.EditedJun 13 2015, 11:57 PM

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.

Tgr added a comment.Jun 15 2015, 1:25 AM

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

Tgr added a comment.Jun 15 2015, 1:27 AM

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.

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.

Fito added a subscriber: Fito.Aug 11 2015, 5:30 PM

(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?

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 11 2015, 5:30 PM

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

Vibhabamba added a comment.EditedAug 11 2015, 6:14 PM

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

Fito added a comment.EditedAug 11 2015, 6:17 PM

@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 =)

Tgr added a comment.Aug 11 2015, 10:07 PM

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.

Tgr added a comment.Aug 12 2015, 8:54 PM

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.

Krinkle removed a subscriber: Krinkle.Nov 2 2015, 10:41 PM
Catrope removed a subscriber: Catrope.Nov 13 2015, 7:41 PM
Isarra moved this task from Backlog to Scary on the Vector board.Apr 7 2016, 1:05 AM
Isarra moved this task from Scary to Typography on the Vector board.Apr 7 2016, 1:08 AM
Danny_B added a subscriber: Danny_B.May 5 2016, 9:07 PM

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

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

Jorm removed a subscriber: Jorm.Jul 6 2016, 9:02 PM

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