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

@Bugreporter, there is nothing wrong with the translation in translatewiki. The current problem is Mediawiki uses
Category:Something rather than Something to replace $1 in the system message.

The patch is scheduled to be deployed around 2020-08-10 11:00–12:00 UTC

The patch will be deployed around 2020-08-10 11:00–12:00 UTC

The patch works flawlessly, but it is best for us to consider how we should be dealt with the puppets that are still requiring Parsoid/JS (see T259988)

Adding Release-Engineering-Team based on Maintainers list.

@Legoktm I am on Linux using addshore's mediawiki-docker-dev. I used a clean installation with CLI.

@Legoktm @cscott I have retried with both the latest master branch as well as REL_1.35 branch of MediaWiki core and VisualEditor. I set up MediaWiki by using addshore's mediawiki-docker-dev. I have only put wfLoadExtension( 'VisualEditor' );, and it unfortunately still does not work.

In T258584#6359651, @Iniquity wrote:

In T258584#6359066, @Jdforrester-WMF wrote:

That large a hover trigger area probably isn't great from an accessibility standpoint (too much of the screen flashing in response to user action).

Hmm, It seems to me that it is good that the entire button is blinking, maybe I'm wrong.

I think it still follows W3C accessibility guideline on hovering, and better as there is no longer the need for users to exactly position of the video play button.

Due to the current un-deployment of Graphoid (See T242855), declining the task as won't be fixed.

@cscott, I will move this to the future idea for consideration, as we will need to move away from an on-page handwritten rule-based system to an automatic system with customized dictionary per page generated by Wikidata (Tools like OpenCC support customized dictionary on top of standard dictionary for conversion).

For the discussion, It should be considered a consensus has been reached. However, the task is still stalled due to T44473.