@MarkAHershberger I think the reason there is no +2 is because no one with a +2 right have time or willing to review the patch.

In T295187#7489948, @Jdlrobson wrote:

Having a project that uses LanguageConverter in group 1 wikis and having a beta cluster version enabled would have also helped flag this earlier.

My understanding is that this support is not natively part of MediaWiki/core, but rather has been added in a non-standardized way by the projects themselves(?)

No, Language Converter is part of the MediaWiki/core (under includes/language/LanguageConverter.php), thus adding MediaWiki-Language-converter and Chinese-Sites for tracking.

In T291985#7464161, @Fomafix wrote:

@Jonathan5566 Can you create a new but report?

@Legoktm Thanks for fixing this!

In T293050#7444425, @TheDJ wrote:

Wasn't easy timeline moved to Shellbox ? Probably those Kubernetes hosts don't have the entire set of fonts they require I guess ?

This suggest solution from T22825 needs to implement in the Kubernetes host based on solution from T274822

This might be an issue with operations/mediawiki-config, causing the font files not linked for display.

@Seddon It may be best to upgrade to Vega 5.21.0

It seems that the remaining Vega 1.5 usages are simple bar graphs, which should be easily upgraded by using the Module:Graph or manual updates.

Vue 3.0 is officially released.

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

Maybe just rename variantname-kk to ‘unconverted’, which is what Chinese does in https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/refs/heads/master/languages/i18n/zh.json. This should help reduce confusion.

Adding MediaWiki-Language-converter since it is the part of the core that is responsible for language conversion. Adding Platform Engineering assume they are the current maintainer of language converter.

I do not believe this is an issue and the limit should not be changed. For example, the three character caption only mention the name and nothing else. Such caption is bad and meaningless as it does not provide any information at all, like is it a portrait, a photograph, a drawing?

In T261153#6414788, @Krinkle wrote:

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.

In T261153#6414485, @Jdlrobson wrote:

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.

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

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

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

Community as stated clearly that the Simplified Chinese logo will be dropped, thus reopening the task.

As Chinese Wikisource has both Simplified/Traditional logo currently in use, the change should not preceded until a Simplified Chinese logo has been provided, or the community decided to drop Simplified Chinese logo support.

Schedule to deploy around 2020-08-24 11:00–12:00 UTC.

@Jdlrobson, @Urbanecm: zh-classic (Classical Chinese) is not the same as zh (Chinese), and adding the wordmark as zh only, rather than project-specific, such as zhwiki is crazy. How can this even pass the code review?

In T237688#5738492, @Izno wrote:

IE11 is still some 3% of total views (7.6% of desktop) and is presently the only MS browser available on Win7 (mind you, an OS basically EOL in a month) and Win8. (Chromium Edge supports both but will be released more-or-less with the end of support for Win7; how it will end up on users's computers for Win7 when they won't be receiving updates, I do not know (voluntary download? for people using IE11...).)

Chromium-based Edge still does support Windows 7 and Windows 8 right now, and anyone who still using IE 11 should start the switch now (either voluntarily, or forced as Microsoft has pulled the plug)

In T178356#6392116, @Aklapper wrote:

@VulpesVulpes825: For the records, T232563 mentioned 1% as a potential threshold but numbers were <0.2% when taking action. Similar number in T147199.

What about
a. Upgrade to Vega 5.0 and Support Vega-lite 4.0
b. Use Vega’s own Server-Side Deployment using Node.js to generate PNG, SVG or Canvas for server-side rendering.
c. If server side did not finishing rendering, we then start client rendering and use Vega 5.15’s Expression Interpreter to ensure CSP.

I am curious about the current status of this task. Currently, the overall IE traffic is around 1.3%, and desktop IE traffic is around 3.7% (based on analytics). Maybe it is a good time to consider starting to drop IE 11, so we can move on to ES6 considering how low the traffic right now.

In T45616#1440377, @Yurik wrote:

Once we update graph extension to vega 2.0, we can have interactive graphs.

I do not know if it is possible to pass the mediawiki system version info to the puppet file, so we can simply to an if statement for to Parsoid configuration.

@alexhollender, thank you for your detailed explanation. However, I still quite not understand the thought for going from step 3 to step 4. I believe for ordinary users, such design choice failed to communicate that " the space to the right and left of the header is essential 'out of bounds'". A simple question a user might ask is "why there also a blank white space between the outer grey one and the content itself". I personally prefer your design in picture 3 if that is possible.

It is now deployed and the Template Editor Protection is available at Special:已保护页面

Now deployed and working.

Is your iOS system language also in zh-Hans-CN?

Scheduled for deployment on 2020-08-10 11:00–12:00 UTC