I think some mark-up might be interesting to keep, to see how the translators handle it. Then again, this is just check if they can choose a correct language and provide reasonable looking translations.

I'm going to be bold and close this. I've seen people confused whether translatewiki.net supports GitLab (we do). The context for this task when there were plans to migrate everything to Gitlab. The current process works for adding one repository at a time without too much overhead. Only thing missing that could still be added is mediawiki-i18n-check with possibility of using to automatically merge pull requests.

Thanks for checking. The closure in MessageGroupSubscriptionHookHandler::onBeforeCreateEchoEvent() was removed in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Translate/+/1334960/9/src/MessageGroupProcessing/MessageGroupSubscriptionHookHandler.php, so maybe this issue is already fixed?

Not sure how manageable it is, different versions of Android support different codes. But if possible, I think it would be a nice improvement to reduce manual work.

This needs updating in translatewiki.net config too, otherwise it will keep recreating it.

We have Projects namespace now for this purpose.

We have switched over traffic, with some small follow-ups to do.

PR was merged.

Please see T376831: Make TranslationAliasesDirs stable and remove experimental note and T431561: Convert special page aliases to translatewiki-friendly JSON format where we could use some help. The step after that would be thinking through how to expose them to translators on translatewiki.net with sufficient validation that they cannot break things.

I see no need to ensure reliability to such a high degree. I would also like to see a plan that doesn't just build more stuff next to the existing relays, but builds shared infrastructure for them.

@Yaron_Koren Please use the template https://phabricator.wikimedia.org/maniphest/task/edit/form/33/

Sep 3 run was successful.

In T437232#12296342, @Tacsipacsi wrote:

The case of #FORMAL illustrates why the rules should be able to consider the MW version and the message content, but it’s not language-dependent. Could you add an example highlighting the need for restricting certain rules to certain languages? I can’t think of any.

I (with help of AI) looked into where the disabled/gray language selector state in Minerva/MobileFrontend came from, and whether there is a historical reason to preserve it.

Can you list the images we maintain and which one of those require an update?

We use Debian stable, where having older versions are expected: the point is to get a stable software stack with security and important fixes backported.

Or let's use something that Debian devs have packaged and do support (I assume they do security updates)?