In T433171#12203709 schreef @LSobanski:

with the additional information, is this still high priority and at risk of removal from your side?

Not sure if this is enough to consider this task resolved or not?

there's benefit to keeping our TWN integration.

This appears stalled, just when there was light in the dark. How to get it going again?

In T433166#12166812 schreef @Arian_Bozorg:

Yes, this project is still active and being used! This is one of the tools that people can use to query Wikidata and it will be important for us to maintain translation support for it

Subscribing the policy makers according to https://sonarcloud.io/organizations/wmftest/quality_profiles/changelog?language=php&name=MediaWiki+-+PHP

How can we get this going again?

@Nikerabbit Is it useful to keep this open? Is the case in the description still current?

I've looked at the code and there are a few things that need to be decided before we can implement a fix. Specifically:

@Amire80 Can you please test, as @Pginer-WMF requested a couple of years ago?

This was resolved as a side effect of commit 6a404e9 ("Remove IE support code", merged 2025-02-16), which removed the entire IE 8/9 HTML5 display-definitions block from resources/libraries/normalise.css, including the summary { display: block } rule that was suppressing the disclosure triangle. No other rule in Timeless currently overrides display on summary or details, so the browser's native display: list-item default for <summary> is fully restored.

Both packages are confirmed absent from the live server. composer show (without --all) on /srv/mediawiki/workdir shows neither davefx/phplot nor fgrosse/phpasn1 is installed. The earlier --all output was misleading as it includes packages available in configured repositories, not just installed ones. Closing as resolved.

TwnMainPage now shows 129k and https://translatewiki.net/wiki/Special:LanguageStats?language=en&x=D shows 128.740. That's close enough to close this as resolved.

In T433171#12159194 schreef @Ladsgroup:

The repo is basically there to hold translations and then we push those to mailman servers. So by nature it should be only translatewiki commits and nothing else.

I just tested this on twn, and wasn't able to confirm the issue. There was only a single translation, though. Steps to reproduce:

In T433170#12156848 schreef @Dreamy_Jazz:

As far as I know there is no regular sync of the translations, but I have pulled the latest translations now. The last pull seemed to be in 2025 and from that we saw maybe 50 or so translations. I'll set up a monthly reminder to pull the repo on toolforge

In T281067#12156981 schreef @Bugreporter:

Reopen. CLDR should not be an extension; it should be a library. See Librarization and https://www.mediawiki.org/wiki/Manual:Developing_libraries

A library is something that is usable even outside MediaWiki ecosystem - language-data is an example.

Related: T231748

In T322461#11686369 schreef @Raymond:

General solution is to add the autonyms to the CLDR extension.

The four LocalNamesEn.php entries requested in this task were added in July 2021 (Change #701662) and confirmed working:

This task has been open for over 5 years without an implementation plan, assignee, or volunteer. Closing as declined.

The original issue has been resolved. The rebuild.php mapping ( az-arab  →  azb ) was fixed in 2016 (caf6312ab36d), and both codes now have correct English display names:

Ukrainian language name coverage in CLDR has improved substantially since this was reported in 2017. The extension now has ~750 Ukrainian language name translations from CLDR 48.2, plus local overrides in LocalNamesUk.php.

This task can be resolved in two ways: Get the autonym updated at CLDR or update it in MediaWiki core. Given that the code is in MediaWiki core, we are technically capable of changing it.