@cscott If I'm not mistaken, https://gerrit.wikimedia.org/r/1200388 can solve this issue?

There are some mentions of TCP Fast Open in operations/puppet: https://codesearch.wmcloud.org/puppet/?q=tcp_fastopen . Though I don't know how the network stack here works.

I have filed the line wrapping issue with 、 (U+3001, used for comma-separator in zh-hans and zh-hant) and the CSS property unicode-bidi at https://issues.chromium.org/issues/477829708. It might not get resolved anytime soon, though.

I found that this extension already splits the parser cache by calling ParserOptions::getUserLangObj() since rEINBe18b7e6 in 2012. In my own test, the options hash part of the parser cache key is canonical when uselang is the same as a wiki's default, but becomes userlang=xx otherwise. I can't reproduce this bug currently, and I wonder how it could happen before.

The screenshot shown is probably in the zh-hant variant. If zh-tw is used, those words should be converted consistently.

I tried making a reply on the page mentioned in the original report, and it works correctly. Thanks to Ammarpad and matmarex for the fix!

In T408324#11488840, @Ammarpad wrote:

Your page seems to have changed.

The reference list items are plain <li>. You will have to define a custom marker scheme with @counter-style in a site-wide CSS, and set list-style-type to it. The cjk-decimal you see is from MediaWiki:Common.css.

I have a somewhat off-topic idea: Switch the encoding of serial numbers from decimal (base10) digits to some base32 scheme. The information per decimal digit is log2(10)=3.3 bits, while one base32 character represents 5 bits. The length of temporary account names will be shortened because more information is packed in one character. Collision will be less frequent due to the increased variety of combinations.

rebuildLocalisationCache.php accepts the parameter --lang. You can limit it to the languages of interest.

The MIME type text/link-preview seems to be supported only by MS Edge, and is lost when copying from Edge to Chrome or Firefox (though that json is viewable with the InsideClipboard util, registered as "Link Preview Format").

The behaviour inside Edge should be working as intended (gerrit #1143196 parses the url and title). Inter-browser pasting to Firefox probably needs some investigation on the format. I suppose Edge's MIME type text/link-preview is lost, so the link is treated as normal HTML and dropped.

Based my understanding, the work needed here is to recreate the entries of Liangent's user pages in the page table (as @Func's queries show the revisions are still in revision); or move those affected revisions to archive and undelete the pages. Are these usually resolved with ad hoc scripts, or more general maintenance scripts would be needed?

That looks nice, thanks! (Regarding the commit message,) I would not call the parameter to \u{N} as "UTF-32", because people write \u{1F602} instead of \u{0001F602} (suppose UTF-32BE is used). That thing should just be called "code point", irrespective of the encoding being used.

Beyond the syntaxes used by other implementations, you can use UTS #18: Unicode Regular Expressions (http://www.unicode.org/reports/tr18/ §1.7 Code Points) to back your feature request. I am not sure how convincing it is.

I noticed that surrogate pairs can't be used inside a character class. For example, both insource:/😂/ and insource:/[😂]/ work, but insource:/[\uD83D\uDE02]/ returns nothing. Using it in character classes can be handy when searching for a range of Unicode code points. Shall I file a new ticket for this?

During the on-wiki discussion, hacky methods have been proposed by @PHING to circuvment this issue:

The feature will be disabled by default in Chromium 143 (https://chromiumdash.appspot.com/commit/b0326c486eede79c80d23b690cd61eceeab159e3).

Personally I'm fine with increasing the font size of (some of the) content text only, and leave less important sidebars as is. It is "broken", however it has been the default mobile browser behaviour for a decade. Users will likely be familiar with it, unless most of the desktop-only web pages they have seen are from pedantic web designers that surpress this behaviour.

In T407447#11300086, @Novem_Linguae wrote:

Can you clarify if you think font boosting is desirable or undesirable?

I tried disabling chrome://flags#force-off-text-autosizing on my Android phone (Chrome 141.0.7390.111). The behaviour indeed returns to the previous one (some of the text are enlarged).

I guess the culprit is https://issues.chromium.org/issues/391990606. The previous behaviour is a feature commonly called "font boosting".

Yes, those requests are sent using curl without cookies, because I don't want to profile lots of load.php/api.php stuffs (with browser cache disabled), or hit the OutputPage::checkLastModified path due to the presence of If-Modified-Since. I might be weird in this regard.

It seems that the patches are not of much help for the two pages mentioned in T405135#11198828. Respectively:
https://performance.wikimedia.org/excimer/profile/52433f65c1598f86 (1.21s, ~unchanged)
https://performance.wikimedia.org/excimer/profile/5c7626da06afdb9e (1.64s, slower, but now there are a few more topics)

zh:Template:Gadget-desc has been optimized by @Diskdance to remove unnecessary Scribunto invocations. The time spent on parsing messages has been cut by half, and the loading speed is comparable with commonswiki now. Profiling sample: https://performance.wikimedia.org/excimer/profile/fe1d4b2e42541990

The issue seems to start from Frame #4. Probably shouldDisplayTalkAlert() is true for you somehow (like you have been ignoring the orange bar). Flow's BeforeDisplayOrangeAlert hook does not catch exception from uuidFromTitle() (unlike elsewhere in that file), leading to the error you see.

I have an idea for follow-up: Can the OutputPageBeforeHTML hook return early if the ParserAfterTidy hook does not find any comment during Parser::parse()? It would be helpful for those content pages in $wgExtraSignatureNamespaces, which can be long sometimes. This does not concern the talk namespaces, and I guess the "empty state" UI elements might depend on it.

(OT) Wow, I really appreciate your diligence! Unfortunately I am not able to comment on the implementation details.

For reference, here are the flame graphs I took on two user talk pages that contain >400 topics:
https://performance.wikimedia.org/excimer/profile/44477ee150bc5d46 (1.27s)
https://performance.wikimedia.org/excimer/profile/f5cfc8e261afbef1 (1.49s)
These requests are sent without cookie, therefore does not contain the postprocessTopicSubscription() part. Only BatchModifyElements is involved.

Lua profiling has not been re-enabled in operations/mediawiki-config. Does that need to wait for T391658?

T351170 shows an example of using the site content language to initialise LanguageConverter. It suffice for the Chinese wikis, though it won't work on some presumptive multilingual wiki that sets $wgLanguageCode to English while supplying MediaWiki:Conversion-nsx. I am not sure if such wiki exists.

I tried this on the beta cluster. Unfortunately, it seems using SpecialPage::getLanguage() is not the correct way to initialise LanguageConverter, as it does not use MediaWiki:Conversion-nsx/xx (same cause as T401493).

Pardon me for asking another question here. I sometimes feel a bit annoyed by the time taken for the OutputPageBeforeHTML hook, as it can take more than 1s on some large talk pages (length alone might not be the problem, probably also related to the number of signatures), and the result is not cached. Is it inevitable by design, or already tracked somewhere in another ticket?

This issue is likely related to an unclosed <div> in an section above it, which was later fixed in rev 88847379. It was only discovered because that unclosed tag and later-added {{Archive top}} templates broke reply tool (and visual editor) on that page.

Can't reproduce. Here it's a relatively normal error page "Invalid value was provided for loading Structured Discussions content."

@thiemowmde: Answering "why uselang=zh still shows the namespace names in English" here. The reason was mentioned in T401499#11074592.

Thanks for triaging. I think the latter one is a better fit. Sometimes it's necessary to realize that wikitext is a weird thing that happens to be mixed with HTML tags :(

Can the wording of this option be changed to, e.g. posting new "topic" at the end of the page, rather than saying it's "section"? That is closer to the reality especially after DiscussionTools' new topic tool is deployed, as that button will open a new topic box at the end of the page, instead of the full wikitext editor (that also appends to the end, but a bit more "section"-like).

An alternative should be using the user-selected variant of the site content language (seems to be obtained through LanguageConverter::getPreferredVariant()) to fetch the message string. If someone bothers to code it.

This issue is also present in Parsoid. I'm not sure how it should be classified.

@Scardenasmolinar I object to this merger, as the original issue here is specific to the implementation of one widget regarding the usage of LanguageConverter, and the fix is mostly complete (except for the case where zh-xx UI language is used with non-zh site content language).

I agree with T174057#4578576 that where to use UI language instead of content language for namespace names can be debatable. However for the Chinese case, the content language itself can change (in the chosen variant sense). The zh language code is mostly for technical purposes mentioned above (like preventing the title name in URL changing depending on the variant), and is rarely used as a display language.

Should wgFormattedNamespaces in JS mw.config (doc) get the same treatment? Currently it is also populated with content language and Language::getFormattedNamespaces() in ResourceLoader.php. The recent changes page mw.rcfilters.js uses this API to obtain the namespace list. However such behavior change could potentially break some scripts on Chinese wikis.

In T174057#4728258, @dcausse wrote:

the new rcfilters UI is not affected by this change and perhaps should. (I failed to find from where the list of namespace is populated in rcfilters).

Special:Search is also affected, as SearchFormWidget is created with LanguageConverter in UI language code (at SpecialSearch.php).

Hi @EBernhardson, I saw you authored the patch in T174057 for which this feature was originally introduced. Do you think some kind of language code prefix matching with $languagesWithVariants is doable in Html::namespaceSelectorOptions()?

I wonder if there is any ready-made ruleset that maps words starting with polyphonic characters to the correct pinyin in that context. A quick search shows that users at zh.moegirl.org.cn (already using Extension:PinyinSort) manually configure the collation key. LaTeX packages authors (zhmakeindex, biblatex-gb7714) suggest similar workarounds.

I'm not sure if this feature is ready to be deployed, as users probably can't agree on the collation method (zh-cn users naturally use pinyin, but not sure about others). Nevertheless I have created a discussion on zhwiki to collect users' opinions (link).

I am not sysop so can't comment on the use cases. However if the customisation has been used somewhere, and the UI of action=protect is kept in its current form, then sysops at zhwiki just have to be less paranoid about the interface or find other workarounds.

I found that "Wikipedia讨论" comes from the templates of NS_PROJECT_TALK in MessagesZh_hans.php or MessagesZh_hant.php. It gets formatted with $wgMetaNamespace which is "Wikipedia", by MediaWiki\Language\Language::fixVariableInNamespace.