I have confirmed that the user agent is being sent as translatewiki.net MediaWiki updater (translatewiki@translatewiki.net). @hashar can you confirm that this would be enough to exempt the machine from the rate limits that we were seeing with Gerrit?

This now tests well on https://test.wikipedia.org/wiki/Special:NewArticle. Its rolling out via the train this week.

Tested on simple English wiki. Created a redirect from NYC_City to New York City. Works as expected.

The change is deployed on production. Will QA for a couple of weeks during deployment to ensure that the issue doesn't happen anymore.

I've documented the approach we plan to take here: https://www.mediawiki.org/wiki/User:APatro_(WMF)/ULS_Rollout_Across_Skins

• Q4: Content patterns are matched against the translation from the development branch.
• Q9: Rules are global. Only MediaWiki core, skins and extensions have backports and they all follow the same rules.
• Q10: Sorry, the question was not clear. I agree with both points. Rules are checked only when the development branch has a translation. When a translation is removed, no rule applies, even a rule without a content pattern. When a rule skips a translation, the target branch keeps its current translation.

Some thoughts:

Another way to fix this: bin/clupdate-git-repo already avoids puppet by exporting GIT_HTTP_USER_AGENT. Adding the same line to bin/wikiupdate-repo would work too.

Entered KHK2017 165 --> picked [KHK2017] 165 --> title is (KHK2017) 165

@eamedina Is the ArticleGuidanceRedirectEnabled set to true for Betawiki? I don't see it: https://codesearch.wmcloud.org/search/?q=ArticleGuidanceRedirectEnabled&files=&excludeFiles=&repos=#operations/mediawiki-config

Will be riding the train this week.

Release is complete. Moving it to needs QA for monitoring.

We're not sure about the future of the feature deployed in T433483: Redirect "suggest a new type" to per-wiki talk page with localised message template. It doesn't make sense to add a community configuration and then remove it later. We're putting this on hold until we have more clarity.

@hueitan Please see the original issue (T431596: Duplicate language selector box) that was being solved by the higher z-index. Increasing the z-index will cause that issue to re-appear. We may need to be able to specify z-index for different instances of the language selector.

@KartikMistry I did a quick test of the server and it seems to be working well. I think we can mark this task as done, unless there is something else pending.

Commit: https://github.com/wikicollabs/dustpan/commit/8cd6f57d5b61528bd87ce08eeb8f7a1cf3b0e781

Exports: https://gitlab.wikimedia.org/toolforge-repos/wikinewsie/-/commit/746ce195613f6ebf8785e0d80e2659002d799adb

Exports: https://github.com/mywikis/NamespaceManager/commit/f224d8c8e189033bb79cd82acdfb5fad4a2a387f

Tests well on Test Wikipedia:

The server setup is completed and all traffic is now moving towards web3.translatewiki.net.

I think ULS should still be available and open entrypoints when there are no interlanguage links. An explicit visual indicator to show that there are no inter-language links would be good to have but not mandatory. Just displaying it as an active clickable item is better than what we have right now.

Tested on https://ar.wikipedia.org/wiki/%D8%AE%D8%A7%D8%B5:NewArticle

Waiting for exports to happen on Thursday.

Project is available for translation: https://translatewiki.net/wiki/Special:Translate?group=mwgithub-namespacemanager

This is done, and deployed on translatewiki.net. The old cron has been removed.

PR looks good from our side. Waiting for feedback from Edly team before resolving.

Pull request: https://github.com/wikimedia/openedx-translations/pull/15

Tested this locally by pulling the latest versions. Works well.

From web3:

$ puppet --version
8.10.0

From web3:

$ curl -s localhost:9200 | grep -E '"number"|"distribution"'
    "distribution" : "opensearch",
    "number" : "2.19.5",

Testing the patch by modifying one of the language codes in the DOM:

Note that after we switched to the MultiselectLookupLanguageSelector.

All the groups have been enabled. Upstream fix: https://github.com/wikimedia/openedx-translations/pull/16

In T433298#12238907, @JeffreyWang wrote:

@Nikerabbit - i18n strings are in a stable position and @translatewiki has been added on GitHub to this repo with write permissions to the main branch.

We're still echo'ing the variable based on the current skin and the supported skin list (wgULSLanguageSelectorV2SupportedSkins) so that usage can continue to stay.

Another thought: we could detect the indentation from the source language.

In T429122#12251320, @Nikerabbit wrote:

Question: I'm wondering if its fine for Minerva to make the assumption that it will always be supported and ULS v2 will always be available on that skin. We can make that assumption, but will have to update the config (wgULSLanguageSelectorV2SupportedSkins) description in ULS to mention that specifically to avoid accidental breakage.

Maybe we can leave it for now or replace it with more robust check.

Additional note regarding the fallback page handling. The fallback page is the ArticleGuidance talk page on mediawiki.org, and on that it doesn't make sense to have a localized subject title, so that will only be in English.

In T429122#12245274, @Nikerabbit wrote:

There is an open patch.

In addition to that,twn config should be cleaned up. And what about the check in the minervaNeue skin?
https://codesearch.wmcloud.org/search/?q=wgULSLanguageSelectorV2Enabled&files=&excludeFiles=&repos=