Page MenuHomePhabricator

Some visual styles affecting fonts are lost
Closed, ResolvedPublic


As illustrated below, Content translation (dashboard, translation editor and stats views) is showing UI labels using serif fonts now, which suggests that some styles may be missing.

The tool works as usual but it looks as if it was broken or not fully loaded:

Screenshot 2020-01-21 at 14.01.39.png (610×1 px, 85 KB)

Screenshot 2020-01-21 at 13.59.55.png (520×347 px, 38 KB)

Event Timeline

Pginer-WMF updated the task description. (Show Details)

I confirm. I saw it myself, and heard complaints from multiple people.

Might be related to the desktop refresh project. I believe I saw some changes to the way default skin styles are set up, and our custom code that loads them may need updating.

Change 566697 had a related patch set uploaded (by Nikerabbit; owner: Nikerabbit):
[mediawiki/extensions/ContentTranslation@master] Re-attempt to use Skin::getDefaultModules

Because of missing vector style, the font-family for all elements in dashboard were missing. This caused it to fallback to browser defaults. After Niklas' patch, we have font-family: sans-serif as the default inherited font. It will make sure dashboard has sans-serif fonts. But, it is nearly equal to not having any font-family styling - that anyway is a bigger problem with mediawiki frontend.

Change 566697 merged by jenkins-bot:
[mediawiki/extensions/ContentTranslation@master] Re-attempt to use Skin::getDefaultModules

Change 572089 had a related patch set uploaded (by Zoranzoki21; owner: Nikerabbit):
[mediawiki/extensions/ContentTranslation@wmf/1.35.0-wmf.18] Re-attempt to use Skin::getDefaultModules

Change 572096 had a related patch set uploaded (by Krinkle; owner: Krinkle):
[mediawiki/extensions/ContentTranslation@master] Document origin and reason for core code duplication

@santhosh I've added documentation references to the original place this code was duplicated from. Core has been calling $out->loadSkinModules( $skin ); in this place for a long time, so matching that makes sense and cleanly resolves the issue.

Although the OutputPage::output() code has not changed recently. The call to loadSkinModules() has been mandatory for much longer, and there was already a long list of differences between the hard coded module list CX had vs calling loadSkinModules(). But I guess those smaller differences were perhaps not noticed by users, or not seen as regressions, or not traced down to their root cause. The internals continue to be changed behind mediawiki.skinning in the recent weeks, and I guess something in there caused the font setting to also be set now in a way that the CX code could no longer find, so it caused a more noticable change.

Change 572089 abandoned by Zoranzoki21:
Re-attempt to use Skin::getDefaultModules

I believe that all wikis will have new version this week...

Change 572096 merged by jenkins-bot:
[mediawiki/extensions/ContentTranslation@master] Document origin and reason for core code duplication