Page MenuHomePhabricator

Chinese Wikipedia’s wordmark and tagline should change based on variant selection
Closed, ResolvedPublic

Description

This is a follow-up task from T258552. There are two variations of the Chinese logo and wordmark. Depending on which variant you've selected in the dropdown menu you will see one or the other.

zh

variants:

  • default(?)
  • 香港繁體/zh-Hant-HK
  • 澳門繁體/zh-Hant-MO
  • 臺灣正體/zh-Hant-TW
zh-hans logo

variants:

  • 大陆简体/zh-Hans-CN
  • 大马简体/zh-Hans-MY
  • 新加坡简体/zh-Hans-SG

Event Timeline

@VulpesVulpes825 currently the logo only seems to update if I'm logged-out. Do you know if this is intended?

@alexhollender, you mean the current project-logo? Currently, since MediaWiki does not currently support variant changes for logos in the core, Chinese Wikipedia relies on its Common.css for the variant change. I am very inventive to mark this task as a duplicate of T260908, as I have already upload both of the wordmark and tagline for Chinese Wikipedia when I fix the error caused by T258552.

@alexhollender, you mean the current project-logo? Currently, since MediaWiki does not currently support variant changes for logos in the core, Chinese Wikipedia relies on its Common.css for the variant change. I am very inventive to mark this task as a duplicate of T260908, as I have already upload both of the wordmark and tagline for Chinese Wikipedia when I fix the error caused by T258552.

Apologies for the confusion on my part, I am still learning how things are working.

When I go to https://zh.wikipedia.org/ I see:

if I change the variant to 大陆简体/zh-Hans-CN or 大马简体/zh-Hans-MY or 新加坡简体/zh-Hans-SG, I see:

so the logo changes based on the variant I am on. But when I check on beta-cluster (https://zh.wikipedia.beta.wmflabs.org/) I do not see the logo updating based on the variant. That is why I created this task, so we can make sure that function is still working in the new Vector.

@alexhollender: This means that the common.css in beta cluster is not updated with the variant part.

Below is a screenshot of the relevant css in Chinese Wikipedia’s Common.css.

VulpesVulpes825 renamed this task from Upload Chinese logo and wordmark SVGs to Chinese Wikipedia’s logo and wordmark does not change based on variant selection.Aug 25 2020, 12:33 AM

Changing the title as the wordmark and tagline as been uploaded and deployed via patch 621542.

alexhollender renamed this task from Chinese Wikipedia’s logo and wordmark does not change based on variant selection to Chinese Wikipedia’s wordmark and tagline should change based on variant selection.Aug 25 2020, 1:17 AM
ovasileva lowered the priority of this task from High to Medium.Aug 26 2020, 6:02 PM

This will not be supported by MediaWiki:Common CSS in new Vector. This needs to be done as part of the software. this comes at a benefit as it means they can also work on mobile for example. Right now the fact that they don't seem to work for logged in users is a little concerning.

We probably need to extend wgLogos to support language variants of logos. If SVGs can be provided for the new logos, I can start thinking about the architecture for that. I'm not sure if that belongs in ResourceLoaderSkinModule::getAvailableLogos or in Vector itself. Probably the former. Vector shouldn't need to worry about the logos it chooses,

Right now the fact that they don't seem to work for logged in users is a little concerning.

Right now the project logo variant change is supported and working for both logged in and logged out users on Chinese Wikipedia (not the beta cluster one). So please do not worry to much.

We probably need to extend wgLogos to support language variants of logos.

That will be great, which can also solve the issue that current logo delivery logic: both Traditional and Simplified needed to be served and then Traditional version is replaced by Simplified version using Common.css. This causes Traditional version never being used, create an unnecessary delivery, which the bandwidth can adds up if serving huge amount of users.

In the context of T140664, it's important to consider how we implement this. I think the vast majority of the layout HTML should be agnostic to the current user and page title (and thus page language), varying only by site-wide config and shared user preferences tuples, such as the interface language. The reason this matters is that it allows future skins and things like offline PWA/SW-based setups to flush the "app shell" based on cached and pre-compiled templates for the current site/skin/userlang combination.

All that to say, in the future model of the skin being infused with "skin data", "page data" and "personal user data", we'd want this to come in through "skin data" (varying by site and user lang).

The good news is that this seems to be how it currently works as well, which I didn't know. URls such as https://zh.wikipedia.org/zh-hans/Wikipedia:首页 don't just apply the language variant to the content, but also effectively (but not actually) setting uselang= internally. And the CSS selectors currently used on zh.wikipedia.org are derived from the <html lang=""> attribute being set as a result of this.

The impact of this current (and architecturelly future-proof) model is that if you are logged-in, the skin language and logo are not affected by which language variant for the content you are viewing. If your user preference is set to zh-hans then you can still switch between variants for the content, but the skin and logo remain consistent.

Likewise, if your language is set to something entirely different (e.g. Dutch, or English), then you'll see the default zhwiki logo regardless of which language variant. This makes sense, but is something to keep in mind while debugging. It took me a while to realise why I couldn't see the CSS hack apply when using the above URL (because it does and should be based on interface language, which for logged-ins is not influenced by the lang variant URL).

TLDR: LGTM!

The impact of this current (and architecturelly future-proof) model is that if you are logged-in, the skin language and logo are not affected by which language variant for the content you are viewing. If your user preference is set to zh-hans then you can still switch between variants for the content, but the skin and logo remain consistent.

I need to ask others, such as @Shizhao and @Xiplus, but I do not believe such restriction for logged-in user is intentional. And such model is not future prove (this is way we have this ticket) is because using css can not replace the wordward and tagline (which we can do for project-logo since they are background image).

I think the vast majority of the layout HTML should be agnostic to the current user and page title (and thus page language), varying only by site-wide config and shared user preferences tuples, such as the interface language.

If such use is needed for all Chinese Wikimedia Projects and potentially all projects that utilize language converter, then it should reside in Skin.php, just like what we do to printout all alternative language link in the getLanguages() in Skin.php. Doing so would also solve the issue that current logo delivery logic: both Traditional and Simplified needed to be served and then Traditional version is replaced by Simplified version using Common.css. This causes Traditional version never being used, create an unnecessary delivery, which the bandwidth can adds up if serving huge amount of users.

Change 627939 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/core@master] Allow logos to be altered by current language variant

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

I've proposed a possible solution to this above. Not sure if it's viable so any feedback would be appreciated.

Change 628419 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[mediawiki/skins/Vector@master] Vector supports language variant logos

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

Change 627939 merged by jenkins-bot:
[mediawiki/core@master] Allow logos to be altered by current language variant

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

Change 628419 merged by jenkins-bot:
[mediawiki/skins/Vector@master] Vector supports language variant logos

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

Change 628897 had a related patch set uploaded (by Jdlrobson; owner: Jdlrobson):
[operations/mediawiki-config@master] Define Chinese logo variants for Modern Vector

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

Change 628897 merged by jenkins-bot:
[operations/mediawiki-config@master] Define Chinese logo variants for Modern Vector

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

Mentioned in SAL (#wikimedia-operations) [2020-09-21T18:21:39Z] <catrope@deploy1001> Synchronized static/images/mobile/copyright/: Update Chinese logo variants for Modern Vector (T261153) (duration: 00m 56s)

Mentioned in SAL (#wikimedia-operations) [2020-09-21T18:25:15Z] <catrope@deploy1001> Synchronized wmf-config/InitialiseSettings.php: Define Chinese logo variants for Modern Vector (no-op) (T261153) (duration: 00m 57s)

Mentioned in SAL (#wikimedia-operations) [2020-09-21T18:26:47Z] <catrope@deploy1001> Synchronized wmf-config/CommonSettings.php: Define Chinese logo variants for Modern Vector (no-op) (part 2) (T261153) (duration: 00m 56s)

This should be fixed now on the beta cluster. The variants https://zh.wikipedia.beta.wmflabs.org/zh-hk/Main_Page and https://zh.wikipedia.beta.wmflabs.org/zh-sg/Main_Page for example show different logos.

@VulpesVulpes825 @Shizhao would you mind checking all the different variants are showing the correct logos there?

Change 629065 had a related patch set uploaded (by Ammarpad; owner: Ammarpad):
[mediawiki/core@master] Pass pageview langcode to SkinMustache::getLogoData()

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

@Jdlrobson It shows the correct logo, thank you for your patch.

@VulpesVulpes825 can you confirm this is working in production now on zh.wikipedia.org ?

Change 629065 abandoned by Ammarpad:
[mediawiki/core@master] Pass pageview langcode to SkinMustache::getLogoData()

Reason:

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

I can verify different logos show for different variants. Please open a new task if any follow ups are required!