With ?uselang=hu, I do see Arabic on the Arabic page. Maybe the canonical English parse was done before the row of the page was inserted in the database?

With the implementation being in Rust, it needs to be added as a microservice (if the setup supports that – WMF production certainly does, but I’m not sure about translatewiki.net, let alone third-party wikis), it cannot be added to the extension directly. Is there any reason you wrote this in Rust rather than in PHP?

Some background: The tracking category was added for T324139: When the lede section has comments, they should not be pulled into the "Learn more" popup. It’s disabled by default, but can be enabled by creating MediaWiki:Discussiontools-comments-before-first-heading-category. The tracking category is added in rEDTO includes/CommentFormatter.php:445 (at 8a18c123d37a5bf8cabce1f35d913e6f72ea8247), which is called from two hook handlers living in rEDTO includes/Hooks/ParserHooks.php (at 8a18c123d37a5bf8cabce1f35d913e6f72ea8247): one for ParserOutputPostCacheTransform and one for ParserAfterTidy.

Side note: you may want to link to the form I used (https://phabricator.wikimedia.org/maniphest/task/edit/form/43/) rather than the generic https://phabricator.wikimedia.org/maniphest/task/edit/form/1/, so that people are guided how to report a bug.

Same for the regex \b(tright|tleft)\b (https://global-search.toolforge.org/?q=%5Cb%28tright%7Ctleft%29%5Cb&regex=1&namespaces=&title=), I guess it’s the same underlying bug?

(Closed by new Phab account, who has an indefblock on-wiki. The bug may have been fixed in the meantime, but I’m pretty sure @Nawaf2296 didn’t test it before closing.)

Actually, the clock used to be in the personal menu. I argued multiple times on https://www.mediawiki.org/wiki/MediaWiki_talk:Gadget-UTCLiveClock.js that it should remain there, but others had other opinions. If there’s still no willing to revert this decision, it should also be possible to add the clock at both places and hide unnecessary ones (based on screen size) using CSS. (Even earlier, the watchlist button also used to be in the menu, but I guess people were dissatisfied with it being one more click away, so Vector 2022, which started as a cleaner skin than Vector 2010, has slowly become IMO just as bloated as its predecessor.)

A very hackish solution (but the whole code is hackish, so it wouldn’t make it that much worse): what if the config code directly accessed $_REQUEST['action']? That would mean no need for changes in VE or DT.

Yes, this is noted by the description (it refers to this issue as “non-prose data”).

As I wrote, I think moving them the other way round would be a better idea. In any case, ukwiki was solved in this task, ruwikinews was recently solved via T423578: Remove custom user groups from Wikinews (in core-Permissions.php), are there any other wikis with permissions at both places?

@Legoktm There’s an open patch by you. If you unassigned the task, maybe you want to abandon it. Or do you hope that it’s going to be merged one day without you working on it? (My interpretation is that it’s waiting for you, but you may think otherwise.)

In T426732#11947138, @1F616EMO wrote:

The acceptance criteria to (2) is that one can use native wikitext (ideally wikilinks [[...]]) to link to any comments, including those that contains illegal title characters as of now. This can be solved by […] introducing a new magic word (I imagine something like {{#comment:c-Example-YYYYMMDDHHMMSS}}, similar to how we invented {{#interwikilink}} for moswiki) for linking to comments.

Which Template Talk page? The Google doc is still non-public, and there’s no other list referenced in this task.

In T426539#11929091, @SomeRandomDeveloper wrote:

Thanks for notifying me, I think this is caused by c58febaa602036d64f05ae1f831fe08caf321d97 (which is not related to the task you mentioned, but also a patch I made). When ApiEditPage is executed, it only updates $wgRequest and not the request in RequestContext::getMain(). AFAICT this only affects VisualEditor because it uses a DerivativeRequest to call action=edit internally when an edit is submitted.

@SomeRandomDeveloper Could this be caused by some changes around T157658: Factor out a backend from EditPage?

Yes, I’m sure. Adding new parameters to an interface method breaks interface implementations. rMW72c969d6774eebf9ce70ab9b9cd3be7f2426de2f was committed before hook handler interfaces were introduced, so there were no interface implementations to break back then.

My suggestion does allow loading multiple levels at a time, when clicking [expand all] in no-JS mode. I think your suggestion contradicts that (“we only allow loading one depth at at time for given root”), but if I misinterpreted you and we actually mean the same, then it’s great.

In T422073#11909267, @Jack_who_built_the_house wrote:

Is this justified though? Maybe it would be easier for them to switch to using h1-h2? h3's are non-subscribable on top of that.

In T422073#11906027, @Jack_who_built_the_house wrote:

What are the typical uses for <h1> on talk pages?

In T424613#11905504, @jhsoby wrote:

CentralNotice translations are a bit messy because they can be added in two ways: Normally via Special:Translate, which would perform the coercion from no to nb seamlessly, but they can also be added by directly editing the relevant pages in the CNBanner namespace, which seems to have been the case for those 2022 banner messages.

Currently Special:LanguageStats doesn’t allow specifying a root at all, does it? Loading only one level by default makes sense, though I’d like to keep the [expand] and [expand all] buttons (submitting forms or navigating to URLs by default, and preferably loading data using AJAX if JS is enabled) – that would reduce the number of inefficient queries (and also decrease page load time) by default, without losing functionality.

Thanks! By the way, Produnto modules could also rely on https://www.mediawiki.org/wiki/Help:Tabular_Data and Commons (which allows for near-instant appearance of translations and doesn’t require translators to have a third-party account) instead of Banana JSON and translatewiki.net. Tabular Data has already existed when the development in the present task began (although apparently not when the task description was last revised), so the development was already done with a focus on multilingual wikis.

What is Produncto? Could you link to some task, documentation etc.?

In T418197#11886303, @matmarex wrote:

using the browser's "Share" API instead of only copying the link to clipboard

Note that not only Wiktionary is affected – $wgCapitalLinks is also set to false not on a few Wikipedias, namely Lojban (no task), Paiwan (T292415), Sakizaya (T237369), Atayal (T275803) and Toki Pona (T404457). The challenge for these Wikipedias is that https://www.wikipedia.org/ is one page, so it needs to be dynamically updated with the attribute depending on what language is selected.

It doesn’t actually matter for my point whether you mean different language or different directionality. Imagine my native language would be Hebrew rather than Hungarian, and my home wiki would be hewiki rather than huwiki. I’d probably also use hewiki with Hebrew interface, but occasionally would write there in English. Your suggestion would not provide me the opportunity to set the language in DT. (It looks quite feasible, by the way, but IMO not desirable.)

The vast majority of the log entries on https://meta.wikimedia.org/w/index.php?title=Special:Log/pagetranslation&wpdate=2026-04-14&limit=1250 are translation discouragements (1069 out of 1250), did all of them trigger message index rebuilds? If yes, why – how can translation discouragement affect the message index? Not updating the message index on discouragement/encouragement would also have avoided the incident – and would also mean less jobs under usual load.

Did anyone think about using WebSocket? As far as I remember, Phabricator uses it, so it should be possible to do WebSocket in PHP, even though WebSocket is stateful while PHP is mostly stateless.

In T371425#11859075, @Quiddity wrote:

Also, there was this related Tech News announcement a few years ago, but I'm not sure what that class="mw-content-ltr" does in-practice.

In T423779#11858027, @Pols12 wrote:

→ index.php?title=Special:PageTranslation&do=mark&target=SOURCE_PAGE_NAME

I’ve run into the same problem with action=query&prop=entityterms, which has no languagefallback parameter, nor does it allow specifying more than one language. (I also request other data, and I use a generator, so I want to use action=query, especially in light of the API rate limiting that’s being introduced.) Is there a solution I can use right now, or does it need development? If the latter, should I create a new task?

As discussed above, this is primarily a bug in the Parsoid language converter, DiscussionTools is just where it becomes apparent.

I don’t think it should be an option; it should rather be the only way it works. The task title also asks “text marked as being in another language” not to be converted. If a Serbian-language page includes a bit of text marked as being in Serbian (sr, sr-RS), that’s not in another language, so it not be skipped. (If the tagging includes the script, that’s an interesting question, though – e.g. if the page contains <span lang="sr-Cyrl">srpski</span>, whether the language converter should overrule the language tag and convert it to Cyrillic if that’s requested, or whether it should assume that if the author said srpski is in sr-Cyrl, they’ve had reasons to do so.)

The attached change has nothing to do with this task, its commit message just had a typo.

In T423525#11836775, @Jack_who_built_the_house wrote:

The thing is, even if you do understand that, what's confusing is that you have {{plural:$N|}} and {{plural:$N|1=}} in one message due to different phrase structure: compare "21 comments" and "from users (list of 21 users)". It's just that the complexity we have here is irreducable.

In T423525#11832459, @Jack_who_built_the_house wrote:

But here comes another problem. People tend to overlook the fact that in cases like this you need not {{plural:$N|}} but {{plural:$N|1=}}, because the inflection form is not the same for 1 and 21.

ContentHandler::createTextSlotDiffRenderer() only needs a MessageLocalizer, not a full IContextSource, so maybe we should only require that. On the other hand, for symmetry with the other getSlotDiffRendererX methods, it would also make sense to require a full IContextSource.

it is unclear why it is not applied the same in different wikis.

In T344050#11833775, @Lucas_Werkmeister_WMDE wrote:

to me it looks like it should be possible to do this: all the callers of SidebarLinkBadgeDisplay have a parser output or output page relatively available, as far as I can tell, and should be able to use the language of that parser output or output page.

In T423525#11828852, @Jack_who_built_the_house wrote:

In this situation, I presume, it doesn't make much sense to go along with my rationale and we should just remove empty {{gender:}}s and {{plural:}}s to eliminate confusion. What do you think?

Note that mediawiki.ui.button is automatically loaded if mw-ui-buttons are detected in the output, so searching for the module name doesn’t find all of the usage (e.g. Special:PageTranslation is missing from your results). I’d rather search for the class name:

I was aware of that, I wanted to point out that at least two out of three usages can be migrated to not use the context at all – reading my comment again, I see how easy it was to understand it differently, though. (I intentionally wrote “to get the main config” and not “only to get the main config”, but this intention probably didn’t come through.)

Also, GlobalCssJs uses the context to get the main config from it – this wouldn’t need a context at all.

Is it just possible to add another optional param to a hook?

Both checkIPAddress() and createLogRecentChange() access the request as a fallback. Would it be feasible to deprecate not passing an IP address and bot flag, instead of trying to pass a WebRequest along?

If there’s only one caller, which only checks whether the result is zero or not, why does it return a percentage at all? It could return the number of translated units (i.e. $keysWithTranslation) as an integer, without any floating-point operations and thus with absolutely no risk of rounding issues (and without the need to branch on $allKeys being zero), or even simply a boolean telling if count($collection) === 0.

I don’t even think an extra confirmation is needed, but the form should make it clear by choosing appropriate wording (the heading should be Create a page with content model instead of Change content model of a page, the submit button should be Create rather than Change etc.).

I see. In that case, I’d rephrase this task to only aim removing modules other than mediawiki.ui.button, and remove T420685 as a parent task, so that this task can be closed and the remaining two parent tasks can be unblocked soon. (Although it’s not my call, I’m neither on your team nor on the LPL team.) For mediawiki.ui.button, maybe a new task could be created. Looking at the search results for mw-ui-button in the Translate repo, most, if not all, remaining uses would welcome a larger overhaul (potentially using Vue/Codex at most places), so if there’s no time pressure, it’s more efficient to start with that overhaul, without any stopgap solutions.

I saw that, but due to the URL length limit discussed over there, I don’t think it’s realistic to expect people to (voluntarily) always use GET. And rather than (or in addition to) saying “include as many parameters as possible”, I think it’s more important to say which parameters have higher priority – maybe one can use more of the 8000-byte limit if one puts shorter parameters in the URL (say, rvdir=newer&rvtag=foo rather than prop=revisions|categories), yet it’s more useful information to know that they requested revisions and categories (the latter cannot even be deduced from the short parameters I used in my example) than the specifics of the revisions request.

I know that the presence in the HTML is expected. However, this link used to be hidden by https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/extensions/WP25EasterEggs/+/refs/heads/master/resources/ext.wp25EasterEggs/style.css before the extension got disabled in T422548: Deployment: Disable the config flag for extension:WP25EasterEggs – the unexpected part is the link actually appearing on screen. (We could try mass-purge all pages on all Wikipediae, but that would likely bring down wikis.)

In T137584#11791630, @Agabi10 wrote:

If a template/module goes against local policies the way to fix it is fixing the template, not adding workarounds outside the template to force said template to comply local policies.

I agree that the implementation should rely on DT data and only on that. However, as far as I understand the description, you propose completely disabling the sorting on pages with sections not detected as discussions – that’s what I disagree with; instead, I think we should do the best we can, sorting sections detected as discussion topics, and leaving other sections somewhere (e.g. moving them to the top).

The undeployment was a bit too quick, see T422985: WP25EasterEggs disabled but "Birthday mode (Baby Globe) settings" link still present.

I also noticed this. Adding any query string (e.g. https://hu.wikipedia.org/wiki/Kossuth_Lajos?x) makes the link disappear, and without the query string, the browser console shows a warning Skipped unavailable module ext.wp25EasterEggs, so I’m pretty sure it’s a caching issue. The extension shouldn’t have been undeployed before the HTML caches expire (if I understand https://wikitech.wikimedia.org/wiki/CDN#Retention correctly, 14 days).

I guess qq is mentioned because that’s the only directory that is touched both by developers working in Android Studio and by the TWN bot – values-en/strings.xml is only touched by developers, everything else (usually) only by TWN. So other files naturally use consistent indentation, it’s only values-qq/strings.xml where Android Studio and the TWN are edit warring.

What about also encouraging people to pass query submodule parameters (prop=, list= and meta=) in the query string? While this cannot be made generally mandatory (since one can specify multiple submodules at once, it’s not impossible to get over the 8000-byte limit if sufficiently many extensions are installed on the wiki), it can still be useful in cases where it’s under the limit, which is probably the vast majority. It could also be made mandatory in special cases like T419130.

In T248294#11792993, @IKhitron wrote:

So for some namespaces, otherwise noone can reach it without remembering the page name.

I’d rather create an Epic task: “don’t use RequestContext::getMain()” is a hopefully closed-ended thing (even if that closed end is far in the future), which is a good fit for a task. I don’t think that extra features of projects, like board columns, would be necessary in this case.

mw-ui-button is used at a lot more places (Special:Translate, Special:PageTranslation etc.). Is that out of the scope of the current task?

Looking at the resulting code, I noticed that there are three protected fields left: $mName, $mIncluding and $mContext. I’d deprecate those ones as well in favor of the accessors: respectively getName() (getter only), including() (getter/setter) and setContext()/getContext(). According to Codesearch,

• $mIncluding is never accessed directly in subclasses,
• $mContext is written two or three times in subclasses but never read (those writes could be migrated to use setContext()),
• $mName is such a generic name that Codesearch is unusable, but it’s often used within core (where IDE tooling helps finding usage), mostly for writing: when two special pages are very similar (e.g. [[Special:ShortPages]] and [[Special:LongPages]]), one of them extends the other one, and manually sets the name from the constructor, since the constructor of the other page takes no $name parameter. Given that this is the parameter most often accessed directly, I’m not sure if it’s worth cleaning up, but if we decide it’s worth it, such special pages could be refactored to extend a common abstract base class, which does take a $name parameter.

{{ec}} This is riding the train this week. It means that from now on, autoconfirmed users can create pages with any content model, which is needed among others to create MassMessage delivery lists. Changing content models of existing pages continues to be reserved for admins.

We’ve talked about the wrong edit links in T368095: Parsoid shows bogus section edit links. It’s because template transclusions still use the legacy parser, and so Parsoid is not aware of where the heading actually comes from. (This is also why DiscussionTools doesn’t work – it only sees data Parsoid sees. So I wouldn’t call it a separate issue.) The task got closed, but this problem hasn’t been fixed, apparently not even almost two years later.

In T422270#11787858, @matmarex wrote:

I think this should be reported as a bug in Cat-a-lot.

Can we get a bit more information? The task description, as-is, is usable only for people who have access to Logstash and/or Prometheus. (I know it’s hard to write a bot like @phaultfinder so that it delivers useful information while also making sure nothing confidential gets leaked, but then the tasks should be assigned to a group/person that amends the descriptions – and the auto-generated descriptions should make this clear.)

• DiscussionTools could disable re-ordering if its parse detected any non-discussion sections.

In T419171#11766430, @Jdlrobson-WMF wrote:

I believe all the subsequent sections ARE editable. Am I missing something? The screenshot doesn't match with what I currently see in production...

Given that we now have $wgVectorPromoteAddTopic enabled everywhere but enwiki (T379264), and as of last week, all wikis use Vector 2022 (T421289), is this worth pursuing? Other than on enwiki, it wouldn’t affect the default skin on WMF wikis at all.

Looking through the results,

So we can now require a parameter that’s optional at the PHP level. But can we also require its value to be __METHOD__?

Agreed. While I’m not 100% sure if we can call it “mass migration” that one needs to go through translations language by language, but it’s probably the closest we can get to it if we want to ensure at least some level of quality, since each translation unit needs manual review anyway.

As far as I know, Translate hasn’t used tracking categories until now, but I guess it could. Or it could surface this problem on the Special:PageTranslation interface (which is used by translation admins), where it already surfaces some potential issues, for example around the usage of translation variables (<tvar name="…">).

@MGChecker What would you call the context language in a maintenance script? I don’t think this concept makes any sense in scripts. Where do need it?

As far as I see, storing the labels in the parser output is only caching – the item IDs could be extracted and the labels translated post-cache, where we have access to an OutputPage object. Would that be too expensive without caching? If yes, maybe could we cache the labels separately in a per-language cache? Given that there’s only a handful of badges, it wouldn’t grow too big (on Wikidata, 13 badges × ~550 languages selectable in preferences = ~7100 entries in worst case, but probably way less).

I wouldn’t call it GIGO – the empty heading itself may be regarded garbage input, and cause garbage output, but the sections following it shouldn’t be affected.

This is not the recommended markup. The recommended markup would be:

Actually, the current implementation is safer (even if, based on the GitHub comment, this is probably not intentional) – you cannot really be sure the property doesn’t change, since a __get() magic method or a property hook could return different values each time.

You quoted Codesearch and the number of extensions/skins using it, not global search and number of wikis or templates, that mislead me.

In T419130#11711548, @Tgr wrote:

Or maybe it could be worked into cost-based rate limiting somehow? Envoy could let requests with meta=tokens in them through, and then MediaWiki would somehow indicate whether it was a "pure" token request, and Envoy could block it on the way back if not.

Why only signatures? HTML tags are not only in signatures. Also, what about signatures that are already on pages? Converting them as well would be quite some effort. I think it’s easier to just make your syntax highlighter (whichever it is) standards-compliant by it recognizing uppercase tags.

The code you removed didn’t “extract UI components [it] whish[ed] to reuse”, so either the description is inaccurate, or it meant something else (which either still exists or – more likely – has long been removed).

In T251588#6580279, @DannyS712 wrote:

For now, the constraint system is completely internal, and until the backend is fully factored out of EditPage it should probably stay that way. I agree that the "perfect solution" is to eliminate these hooks if possible. The full migration to a backend cannot proceed until eventually the hooks passing instances of EditPage objects are removed, since the backend won't know about EditPage

In T419130#11711406, @Tgr wrote:

action=query&meta=tokens, maybe action=query&meta=authmanagerinfo

FlaggedRevs […] create an EditPage object in order to extract UI components that they wish to reuse.

In T355242#11708726, @Volker_E wrote:

Wouldn't making a truly limited exception to the Codex CSS-only styles by adding .mw-ui-button and related classes there provide a path forward?

I think and hope that the codes are going to be renamed, in the present task, just via other means.

I took “any mobile device” (an Android 16 phone with Firefox 148), and couldn’t reproduce this on Обсуждение:Сент-Клэр, Дейн. Please be more specific:

Could the Action API login endpoints (action=clientlogin and action=login) also be exempted? They suffer from the same issues as OAuth login – one cannot be logged in while logging in.

In T419830#11703255, @cscott wrote:

The backtrace on the recursive invocation caused by <templatestyles> is at {F72821664}

So neither of them are use cases for interpreting the output of {{Special:PrefixIndex}} or <categorytree>, which is what I asked for. For reading the previous heading, the use cases are – and were already – clear, only the technical feasibility isn’t.

In T78171#11688181, @Spartan.arbinger wrote:

frwiki rcu