It looks like we noticed and failed to fix this issue three or four times now ;)

In T317719#8352436, @alexhollender_WMF wrote:

@ppelberg @ovasileva per T316559#8352067 we can remove the language menu from the sticky header on Talk pages. Should I setup a separate task for that, and if so please let me know which board/team it should belong to.

This will break everyone's developer setup of Parsoid, since the recommended way used this property until recently. It broke Patch Demo: https://github.com/MatmaRex/patchdemo/issues/544. You'll get an error like "Fatal error: Uncaught Error: Cannot access private property AutoLoader::$psr4Namespaces". Maybe it'd be nice to deprecate it first… Failing that, I hope people will find this ticket.

May be related to T329299

Previously discussed in T292636, T329584. Although it's not necessary to use {{GENDER:|}} in the English message to enable its use in translations, this question keeps coming up, so I'm increasingly convinced that we should add it to make it obvious to translators. It is also recommended by https://www.mediawiki.org/wiki/Manual:Messages_API#…on_user_names_via_GENDER: "If it is likely that GENDER will be used in translations for languages with gender inflections, add it explicitly in the English language source message."

This takes care of numbered lists, but not bulleted lists, because the bullet icon is an image (at least on Vector).

This change seems wrong to me. The sections should be present regardless of magic words or other conditions that cause the TOC to be shown or not. The API output includes a showtoc: true/false property that can be used to determine whether the TOC should be shown, which should be used by clients, instead of us removing the actual data from the result.

Thanks, I see what you mean now.

Documented: https://www.mediawiki.org/w/index.php?title=Extension%3AInputBox&diff=prev&oldid=5843844

I'm not seeing any issues in the article now. All references are consistently numbered in read mode and in the editor, in article body and in the references list. The usual cause of issues like this is defining a reference in a template, but I'm not seeing any of those in the article.

I filled out the table with special characters, mostly to note which ones definitely won't work and which ones may have issues. Feel free to delete or document if any of the remaining ones would be bad ideas.

It's not actually invalid, so this isn't really a bug. For example, the page exists on English Wikipedia as well (as a redirect): https://en.wikipedia.org/wiki/%C2%AD

This is done now: all new comments being posted are being indexed in the permalink database. Old comments will be handled in T315510 by the maintenance script runs.

Considering that the script has been slower than I'd hoped, and considering that it doesn't seem to be putting any stress on the servers, I'd like to try running a few instances of it in parallel. @taavi told me that "usually it's fine to run scripts on one wiki per section at a time". group2 wikis are distributed between database sections s1, s2, s3, s5, s6 and s7 (roughly evenly in terms of total size: e.g. s1 is just enwiki, s2 has 13 largeish wikis, s3 has 277 smallish wikis, and so on).

(the itwiki run finished a few days ago, we can start group2)

Sure, done.

Following the deployment in T328940, the page now displays as expected for me.

Following the deployment in T328942, the banners now display as expected for me (when revealed using either the "Read as wiki page" button or the "Learn more about this page" button).

Now enabled on all three wikis.

Now enabled on all three wikis.

I can summarize the problem, since I'm familiar with T14974. The short summary is: whenever {{...}} syntax in wikitext [template or parser function] would return a value that starts with * [or a few other characters], it will magically insert a line break before it.

Thanks.

CC @Tgr / @kostajh please check that I'm not breaking anything in GrowthExperiments with these changes, since it does things with the oversampling that I don't completely understand.

CC @DLynch for review.

Request from me: please also update mw.Api#saveOptions in JS, which calls ApiOptions, and currently checks for logged-out users to skip the API request.

I have filed subtasks for each project: