@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

Have time. Currently close to a SWAT deployment window, hoping to get this deployed within the next hour.

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.

Remove Chinese-Sites as the extension has not been deployed to any zh projects.

@Volker_E In short, since the current color for background-color-secondary--modern is similar to the default background color of all major browsers when page not loaded. Having this color when viewing pages gives user the impression that either the browser failed to render the page to the full width of the window, or the website failed to stretch to the full width of the window.

It is now deployed on Wuu Wikipedia. If the logo is not changed when you are viewing the site, please purge the cache.

New Vector skin's max-width should be removed or not based on pixel

Guess I will just have to copy-paste the content from T259099.

Steps to reproduce

1. Turn off the "Use Legacy Vector" option to use the new Vector skin
2. Viewing any pages on a widescreen display (Bigger than 21 inches)

@Lt2818 Have upload a new patchset with the new compressed logo files. Schedule time should remain unchanged.

Scheduled to be deployed on 2020-07-29 (UTC)

Wu Wikipedia is out of scope for Chinese-Sites, hence removing the tag.

This error is caused by an incorrect configuration of CORS by the webmaster of zh.moegirl.org. You needed to convince the webmaster to add the Access-Control-Allow-Origin for zh.moegirl.org, so the cross-origin resources can be shared to zh.moegirl.org.

@Pavol86. Congratulation on finding a Japanese word segmentation package that does not require additional compiling. After my own testing, I believe SudachiPy's word segmentation performance is good enough. However, I believe going with the full dictionary option and the B mode is a better choice, as the A mode segment too much. The A mode basically segments "basic" and "lly" apart. In the Chinese word segmentation guidelines, this is not acceptable.

However, you can try it out now follow instruction listed in T253943: Enable DiscussionTools at all wikis via query string

Stalled due to T252255: Create plan for how DiscussionTools will be scaled to all wikis

Adding CharInsert based on previous comment.

@Hamishcn, this might caused by one of the gadget you have enabled. If possible, it would be great if listing all the gadget you are currently using, so we can find which gadget that cause conflicts with MediaWiki-extensions-CodeMirror.

@Arjunaraoc, this might caused by one of the gadget you have enabled. If possible, it would be great if listing all the gadget you are currently using, so we can find which gadget that cause conflicts with MediaWiki-extensions-CodeMirror.

It can be duplicate of T252965.

It can be changed, but will be difficult as LanguageKk depends on LanguageKk_cyrl.

Currently PDF rendering on beta cluster renders CJK character correctly (Even though the render itself can be improved, see T226633). Will close the task once the patch deployed to production wikis.

@Aklapper This is happening not to one web address, but all Wikimedia projects that are not using Latin/Cyrillic/Arabic script. Currently, CJK script is absolutely broken, as well as some other script like Tibetan. The script that are not been affected can be more than I listed since I do not have time to test every single writing script.

As some editors have bought this issue up in Chinese Wikipedia's Village pump (technical). Adding Chinese-Sites for tracking.

@ArielGlenn This might be a stupid question. Since the template causing an issue is a sandbox for people to try out how templates run, people may put crazy huge things in there (like the one you mentioned above). is it possible to skip all of these sandboxes in future dump?

Adding Chinese-Sites to keep tracking issue that relate to T254627.

Deployed and is in effect.

It is now deployed and synced.

@jeena, @Pavol86 & @Halfak Mecab does have multiple dictionaries to use. I would suggest redoing the testing using JUMAN++ instead.

As Mediaiwki has switched to 57.1 (which is still way behind the current stable version of ICU), is it still the case?

As the final Wikistats-1 dump-based reports have been released, Wikistats 1 is no longer maintained, thus declining this ticket.

What about Noto Sans Egyptian Hieroglyphs?

@fireattack: Sorry, it should be T198965#4438038. I think the main reason Google doesn't honor canonical URLs of projects that uses language converter is because the alternative link is source file does not follow standard.

<link rel="alternate" hreflang="lang_code" href="url_of_page" />