I suspect something failed to purge the cache at the CDN. That page's "Cache expiry" in the parser limit report is already shorter than a day. (CoreMagicVariables.php should set the TTL to 3600s due to usage of {{NUMBEROFFILES}}. Not sure why it's longer there.)

I would say that patch's approach looks hacky and resembles an abuse filter. Changing the template on wiki may make more sense, unless there are other scenarios of the same root cause.

The argument in favor of the discussion's Option 1 and 2 are based on the idea that choosing variants and switching languages are usually orthogonal issues, and most readers won't switch the variant if it's already their preference.

Meanwhile I have opened a Village Pump discussion for this on zhwiki (link).

Implemented at T426532#11956157.

Duplicate of T53242: Support language variant selection at ULS. Implemented at T426532#11956157.

@Diskdance's Variant Ally currently does some of the query parameter patching on zhwiki. I suspect it may need adaptations.

His use case is probably about using Extension:TemplateStyles to style those elements based on the language. Though the .mw-parser-output does inherit the language from its parent .mwe-popups-extract, selector :lang(zh-Hant-TW) won't match the lang="zh-tw" case. He expect the lang attribute set by Extension:Popups to be consistent with the main content.

I still wonder what is the intended behaviour for nested LC markup. It appears undocumented.

The code that sets lang to .mwe-popups-extract is at pagePreview.js.

This is probably working as intended. recentchangestext is accessed with the content language, not the UI language. Therefore only the bare MediaWiki:Recentchangestext is recognized, and its subpages are ignored.

Module:Citation/CS1 also validates access-date, which is probably just a little bit less widespread than specifying the year of the source.

I made the same mistake a while ago (T420029), and agree that a tracking category would be useful. It's nevertheless documented at mw:Help:Magic words (and I remember having investigated how was the namespace-based control done before, so I should be embarrassed for forgetting it).

Sorry, I was not aware of $wgExemptFromUserRobotsControl.

Ironically, a few lines above in LanguageConverter.php says "HTML markups (anything between < and >)" is not converted.

There is no -{T|} or {{DISPLAYTITLE:}} set in revision 90807880. Though it's not used here, zhwiki usually adds -{T|} tags through the parameter T of Template:NoteTA.

The LC tag in the first revision (91658373) is likely manually added by the user (it doesn't start with -{zh-hans:). I will mention the list in the wiki.

In T418549#11659839, @ssastry wrote:

Once we backport scott's patch and we stop further dirty diffs, I'll upload a list of all pages with dirty diffs, so those pages can be appropriately fixed up. As of this moment, we have about 111, with the first one from Feb 24th.

Sorry for making the wrong guess on the background (the title should be correctted later).

Raising the priority as I believe it's as annoying as T411238#11415736. Sorry for the extra housekeeping work if I get it wrong.

That task's description was written by me. I kept the project tags he set, though.

Keep this task as it's earlier and contains more information.

Duplicate of T267067?

Probably Language::formatExpiry() should be used in GlobalBlockLogFormatter.php.

I was referring to something inside ConverterRule.php that I'm not familiar with. They are seemingly undocumented everywhere. Leaving a ticket open might nudge informed developers to document them. Nevertheless, I can undo the status change as I don't have much opinion on this task.

I would say it's not completed yet. The document of the converter syntax should include some details about its inner workings, e.g. bidirectional and unidirectional conversion rules, to aid understanding of its behaviour.

In T416616#11625458, @ori wrote:

I can't think of a reason you'd want to seed the PRNG with the current date except to implement a "random foo of the day" feature, in which case you explicitly want the expiry.

I saw usage of math.randomseed(), where the timestamp is used to seed the PRNG. Should there be a way to obtain the time without parser cache side effect?

A tracking category is too coarse-grained to be useful (when widely used templates like CS1 trigger this issue). It had better be lint-like to allow editors to locate the template and do possible rewrites.

Should T392347 be merged here? That issue is not resolved with Parsoid 0.23.0-a16.2. Sorry, misunderstood the branch model.

In T416616#11616527, @Krinkle wrote:

Example: https://en.wikipedia.org/wiki/António_José_Seguro (linked from today's Main Page)

The infobox contains an "age" that presumably uses a current-time magic word with day-level accuracy where ParserCache expires near the next midnight.

Oops, T417294 should be merged into this ticket.

A slightly OT question: When I see Cache expiry: 1807, is it possible to identify the reason for it? I suspect it comes from the MIN_DEADLINE_TTL (30*60=1800) in CoreMagicVariables.php. The method I have found so far is bisecting a page's source code, and inspect the NewPP report by previewing.

There is a report on zhwiki (link) that the search suggestion feature is broken recently. I suspect gerrit #1217251 causes this regression.

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