In T410267#11454514, @abi_ wrote:

We now have the LookupLanguageSelector on translatewiki.net enabled on Special:PageLanguage (needs permissions) and on Special:AggregateGroups.

Lets throw an error if the language code is invalid.

The changes are now live on translatewiki.net

We now have the LookupLanguageSelector on translatewiki.net enabled on Special:PageLanguage (needs permissions) and on Special:AggregateGroups.

Note that the actual HTTPError: 503: MW API error does not have anything to do with qqq being the target language. The HTTP 503 error is because of the requested API not being available.

I did some debugging locally.

Exports: https://github.com/wikicollabs/broomstick/commit/0a06dfbe1ba03c532adeb325cb78fede8f98ab6e

In T411463#11435455, @Raisha_Abdillah wrote:

Thank you so much! We've sent a direct invite with write access to https://github.com/translatewiki, please let me know once it's been accepted, or if anything else is needed from our end.

@Pppery Can you try renaming: https://meta.wikimedia.org/wiki/User:APatro_(WMF) that has translatable pages under it. It should no longer be possible.

Done as per: https://github.com/OpenHistoricalMap/issues/issues/1219#issuecomment-3568722848

No longer seeing it in Logstash.

We've decided to stick with Action API for backward compatibility and to limit the scope of the work.

In T410000#11408918, @Nikerabbit wrote:

Got clarity for next steps:

This does need a security review. Please use this form to file a task requesting the security review, so that it's tagged with the right things and includes the right information

Some changes and requests in the GitHub repo too:

• https://github.com/wikimedia/language-data/pull/461
• https://github.com/wikimedia/language-data/issues/459
• https://github.com/wikimedia/language-data/issues/460

Created: https://phabricator.wikimedia.org/T411267

In T410366#11382638, @Nikerabbit wrote:

155 occurrences in the last 1 week.

How does this compare to other errors? Is this on top of the list?

In T402882#11405004, @KartikMistry wrote:

MediaWiki Job runner is enabled in both MLEB instances.

In T370714#11394723, @gerritbot wrote:

Change #1208066 had a related patch set uploaded (by Pppery; author: Pppery):

[mediawiki/extensions/Translate@master] Block external attempts to move translatable pages

https://gerrit.wikimedia.org/r/1208066

@Wangombe Can you update what was done for this ticket in addition to renaming the group in group configuration file?

In T407180#11274213, @Tacsipacsi wrote:

Could this include evaluating and possibly updating in-house usage as well? According to Codesearch, it’s used by

• ContentTranslation (including its server),
• jQuery.ULS,
• the UniversalLanguageSelector extension (which parses a JS file from jQuery.ULS in rEULS data/LanguageNameIndexer.php: very fragile, definitely keep an eye on it – or migrate it to language-data PHP if possible) and
• Wikimedia-Portals (that was me in rWPORa921a7050df8493a9a223e1a90b4bc5abaed0a1c).

Other results seem to be false positives, i.e. they don’t use the JS interface.

(I’m not sure how an ES module migration looks like, but I assume it affects consumers, as otherwise it wouldn’t benefit ULS.)

Currently not actively working on this.

Fixed

In T410267#11378566, @Bugreporter wrote:

Should we build it inside Codex?

Note the ULS language selector is also used in WDQS, which calls Wikidata's language search API.

Looking at the code in the Translate extension, we request for supported MT language pairs before making requests so these requests to qqq are not originating from there.

In T404691#11366798, @abi_ wrote:

In T404691#11244829, @Nikerabbit wrote:

Currently using a workaround that requires carrying a local patch on the config repo. Waiting for a fix in core.

Dropped this local patch. Don't see any logspam.

No issues noticed. Marking this as done.

In T404691#11244829, @Nikerabbit wrote:

Currently using a workaround that requires carrying a local patch on the config repo. Waiting for a fix in core.

Change is deployed on translatewiki.

We should follow (atleast some of them) the steps outlined in https://translatewiki.net/wiki/How_to_drop_a_project

In T400067#11349516, @abi_ wrote:

In T400067#11322968, @A_smart_kitten wrote:

It changed it, but it looks like the special wikis are still currently part of the new dblist. (So, judging by @Nikerabbit's comment in T400067#11023613, maybe they should be removed from there?)

The dblist-index.php and the dblists/specialcontribute.dblist are automatically generated via composer manage-dblist which generates the list of wikis using https://gerrit.wikimedia.org/g/operations/mediawiki-config/+/dd5e22173a59cb541d6ed0ba7a879c5f197a6026/src/WmfConfig.php.

We've updated our internal documentation to link to the Observability dashboard list: https://www.mediawiki.org/wiki/Wikimedia_Language_and_Product_Localization/Observability_dashboards

In T400067#11322968, @A_smart_kitten wrote:

It changed it, but it looks like the special wikis are still currently part of the new dblist. (So, judging by @Nikerabbit's comment in T400067#11023613, maybe they should be removed from there?)

Exports happened to 1.45 branch - https://gerrit.wikimedia.org/r/q/branch:REL1_45+owner:l10n-bot@translatewiki.net

@hueitan Using a moving average as a threshold can be unreliable and lead to noisy alerts. For example, an increase from 2 to 3 errors might trigger an alert despite being acceptable. Frequent false positives will eventually reduce trust in the system.