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

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

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,

• https://zh.wikipedia.org/static/images/project-logos/zhwiki-hans-2x.png
• https://zh.wikipedia.org//static/images/project-logos/zhwiki-2x.png

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.

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

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