I suspect this regression is caused by a change introducing <bdi> HTML tag into the username parameter, since that’s pretty much the only thing that seems different

If this is correct, could this have potentially have been caused by the patch in T385876: TempAccounts: properly support RTL scripts on Special:Contributions? (https://gerrit.wikimedia.org/r/1119362)

Ah. Different task but the same authors/principle. You are probably right.

This has caused the regression and the solution is to send gender template input separately from what it should show like 'contributions-subtitle' which isn't the case with 'contributions-title', and it interestingly it specifically says Gender cannot be used here at this time (January 2022 https://github.com/wikimedia/mediawiki/blob/b4550953ff13d11e47c3cef17d0140a46b793065/languages/i18n/qqq.json#L2790

Change #1123410 had a related patch set uploaded (by Ebrahim; author: Ebrahim):

[mediawiki/core@master] i18n: Pass {{GENDER}} input separately to 'contributions-title' message

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

"Gender cannot be used here at this time (January 2022)" apparently was added by @Eihel in https://translatewiki.net/w/i.php?title=MediaWiki:Contributions-title/qqq&diff=prev&oldid=10477492 guess at the time it didn't work either, not sure what happened in MediaWiki to make it work, hopefully a solution like https://gerrit.wikimedia.org/r/1123410 can make it work again.

A better solution might be to put <bdi> tags in the message text, as is done usually in such instances. I don’t think your proposed solution is good as it complicates the translation for no reason.

As to GENDER keyword, it worked since T113346: Add GENDER to username related strings on Special:Contributions before @Eihel’s edit.

A better solution might be to put <bdi> tags in the message text, as is done usually in such instances

Most username in let's say Persian Wikipedia are in latin script and thus LTR. The language of the message and the language of the username are different things altogether.

I think I misunderstood you. I still think it complicates the i18n message a lot.

Well, there’s at least 24 messages doing that elsewhere so there is clearly precedent: https://translatewiki.net/w/i.php?title=Special:SearchTranslations&query=bdi&language=en

And Translate extension does not allow to omit those tags either so that is also not a problem. Although there might not be any guidance to this point, it is best to keep message parameters simple instead of, as is done in the patch, introducing a new variable for non-<bdi> content instead of fixing the old one that worked fine before this change.

That makes every message in need of <bdi> because this isn't needed just for RTL locales but also for LTR locales that need to display registered usernames with RTL text. As a rule of thumb, <bdi> is needed whenever UI text is mixed with user generated text, more on it here T375975#10199315

You are adding those tags everywhere anyway, see for instance https://en.wikipedia.org/wiki/Special:Contributions/Stjn
So what’s exactly the problem with adding them in the localised messages? Not that there’s any point in giving feedback any more considering the patch was merged in 15 minutes despite my objections.

Change #1123410 merged by jenkins-bot:

[mediawiki/core@master] i18n: Pass {{GENDER}} input separately to 'contributions-title' message

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

@Ladsgroup, imo I don't think there was a rush to merge this patch. For one thing it meant that @stjn couldn't give feedback on the patch before the CR+2; and in addition I'm not certain on whether we're meant to be modifying the message translations directly (my understanding was that any changes to the translated messages had to go through translatewiki, but I admit I could be wrong there).

In T387468#10588255, @A_smart_kitten wrote:

@Ladsgroup, imo I don't think there was a rush to merge this patch.

Well, there is. This patch fixes a user-facing issue. You can disagree on how it's fixed but that's the second priority (and IMO, it's a tabs vs spaces discussion, it's not nice to push your style on others). Feel free to make a separate patch to do it "your way"

For one thing it meant that @stjn couldn't give feedback on the patch before the CR+2; and in addition I'm not certain on whether we're meant to be modifying the message translations directly (my understanding was that any changes to the translated messages had to go through translatewiki, but I admit I could be wrong there).

You are wrong :) It recognizes and updates them.

To explain it better, previously the message was straightforward: $1 denotes a username in plain text form. It gets passed into GENDER and that’s also not hard to understand. Now, instead of that, we have $1 which denotes ‘username in HTML form’? and $2 which is also the username but in plain text form. Maybe that sort of complication is warranted sometimes, but here I completely don’t understand why that’s preferable: <bdi> isn’t inserted conditionally, it gets inserted everywhere. Translatewiki already ensures that any HTML tags etc. in the message are required to be present in the translation. So what’s the point to the second variable, especially the one that doesn’t match how the message behaved previously? Looking slightly more clean?

In T387468#10588267, @Ladsgroup wrote:

and IMO, it's a tabs vs spaces discussion, it's not nice to push your style on others). Feel free to make a separate patch to do it "your way"

That’s pretty disrespectful to say when you already merged a patch that complicates that work because now every single message needs to be edited back to the way it was before.

(Also, tabs vs spaces isn’t just a stylistic preference anyway, see https://adamtuttle.codes/blog/2021/tabs-vs-spaces-its-an-accessibility-issue/)

In T387468#10588267, @Ladsgroup wrote:

Well, there is. This patch fixes a user-facing issue.

This is true; however, whether it was merged (e.g.) today, tomorrow or the day after tomorrow wouldn't have had an effect on when the fix was rolled out to WMF wikis. Anyway, I've said my piece here so I won't say any more (but thank you for correcting me on the translatewiki issue /gen)

You are adding those tags everywhere anyway, see for instance https://en.wikipedia.org/wiki/Special:Contributions/Stjn

Before that it was invisible characters all around, and they could end up in clipboard when user copied text from pages and that was worse user experience e.g. T27277 and W3 also suggests against that T375975.

So what’s exactly the problem with adding them in the localised messages?

Guess we have an assumption that translators shouldn't involved with technical details specially when something should be done in every locale.

my understanding was that any changes to the translated messages had to go through translatewiki, but I admit I could be wrong there

That's a fairly common practice.

In T387468#10588289, @Ebrahim wrote:

Before that it was invisible characters all around, and they could end up in clipboard when user copied text from pages and that was worse user experience e.g. T27277 and W3 also suggests against that T375975.

My point isn’t that I don’t understand <bdi> tags. My point is that there is no functional benefit to having a breaking change <bdi> variable when those tags are not added conditionally.

In T387468#10588300, @stjn wrote:

In T387468#10588289, @Ebrahim wrote:

Before that it was invisible characters all around, and they could end up in clipboard when user copied text from pages and that was worse user experience e.g. T27277 and W3 also suggests against that T375975.

My point isn’t that I don’t understand <bdi> tags.

T375975: Reduce relying on hidden direction marks in MediaWiki starts with:
From https://www.w3.org/International/questions/qa-bidi-controls.en.html

Unicode control codes are not useful for bidi formatting when working with structural or paragraph-level markup.
 For inline content we recommend that, wherever possible, you use markup in HTML and XML, rather than the Unicode control characters.

It's an official recommendation from w3c standard. Once that's changed, feel free to come revert the changes.

My point is that there is no functional benefit to having a breaking change <bdi> variable when those tags are not added conditionally.

You rely on LTR languages only, we and hundreds of millions of others write in RTL languages daily and it adds benefit to us. If it doesn't add benefit to you, it doesn't mean it shouldn't be done.

My point is that there is no functional benefit to having a breaking change <bdi> variable when those tags are not added conditionally.

Unless you want to implement bidi algorithm in MediaWiki or some reduced heuristics form of it, that's unconditionally needed both in LTR and RTL locales. And that's not something I started also, invisible characters were also unconditionally added in both LTR and RTL user interfaces.

In T387468#10588368, @Ladsgroup wrote:

You rely on LTR languages only, we and hundreds of millions of others write in RTL languages daily and it adds benefit to us. If it doesn't add benefit to you, it doesn't mean it shouldn't be done.

You keep making it seem like I do not see a benefit to <bdi> tags. Once again, I do not disagree with their addition. I am saying that it should’ve been done in the message text, not in a separate unexplained variable that broke the way the $1 variable worked before. I am not against <bdi> tags. Please stop misunderstanding me.

Looks like the manual changes made to non-English languages in the patch above may have been overridden by the translatewiki l10n-bot. https://github.com/wikimedia/mediawiki/commit/4c8ddb06bb48b55886d3610c07db487fddbf023e

On the surface, it seems like the solution may be to re-apply the manual fixes over on translatewiki itself.

Sorry, I wasn't aware of this task. It is essentially a duplicate of T389491, which I reported. That is already supposed to be fixed, and if I'm not confused about scheduling, the fix is supposed to be deployed by the end of this week.

(As a general recommendation, every task related to messages and translation should have the i18n tag.)

Also, this issue could’ve been completely avoided if there was clear documentation on such avoidable localisation issues that people could point to so patch authors have to introduce new variables instead of breaking the old ones, as happened here with previously working $1, and left the grace period for others to voice their concerns over the direction of their proposed patches. Alas, Wikimedia movement is at many times imperfect.

In T387468#10674571, @stjn wrote:

As it says in I18n, it is a gargantuan non-specific mega tag so forgive me for not marking this task up with that. I’ll try not to forget in the future.

It is indeed gargantuan and resolving all the stuff there progresses slowly, but it actually works for getting attention.

The problems with the patches that caused the problems were:

• Not adding both parameters to en.json and qqq.json.
• Changing the parameters in other languages in Gerrit. It usually shouldn't be done in Gerrit, but in translatewiki.
• The general idea of adding bdi was good, but changing the semantics of an existing parameter was not so good.