Same for MediaWiki:Logentry-oath-verify

	"logentry-oath-disable-other": "$1 {{GENDER:$2|disabled}} the two-factor authentication of $3",
	"logentry-oath-verify": "$1 {{GENDER:$2|checked}} if $3 had two-factor authentication enabled",

and

	"logentry-oath-disable-other": "The template of the log entry message\n\n* <code>$1</code> is the person disabling the two-factor authentication.\n* <code>$2</code> is the user whose 2FA is being disabled.\n* <code>$3</code> is the user whose 2FA is being disabled (again).",
	"logentry-oath-verify": "The template of the log entry message\n\n* <code>$1</code> is the person verifying the two-factor authentication.\n* <code>$2</code> is the user whose 2FA is being verified.\n* <code>$3</code> is the user whose 2FA is being verified (again).",

rEOAT808df6dc551d: Add private logging when user disables 2fa for someone else added the first message, CC @Ladsgroup

rEOAT130e649191a2: Add Special:VerifyOATHForUser to check if users have OATH enabled added the second, CC @DannyS712... I can't obviously see if logentry-oath-verify is actually used (it's not greppable :()

Instead a new parameter shall be added with raw username of user who has performed the action. I assume $1 contains a link

Isn't that what $1 contains currently, as per the qqq entries above?

but the usage in " {{GENDER:$2|disabled}}" is incorrect

I think not the usage is incorrect, but the documentation. Looking at the code, both log messages use the standard logging system, so I think the documentation in translatewiki:Template:Logentry applies—the gender of the user disabling/checking 2FA (actor) can be queried, but the gender of the user whose 2FA is disabled/checked (target) cannot.

I don’t know how much work it is, but maybe the standard logging system could be split into logs whose targets are pages (deletion, page move, upload etc.) and logs whose targets are users (rights changes, blocks, these 2FA logs etc.)—currently only the former is supported, so user-targeted logs store the target as the target user’s user page by convention. Explicitly user-targeted logs would mean that the gender of the target user could be added as a fourth standard parameter, while extensions’ code (and code in MW core that adds log entries) would become simpler and more expressive, not more complicated.

Thanks for the elaboration.

I've forked it into a subtask for fixing/improving the underlying situation in MW Core. Then when that's fixed, we can make use of it here to fix these usages in the extension.

If there's any other similar tasks (in extensions etc), feel free to add T302030 as a subtask. I'm guessing these aren't the only instances!

We can also also do a custom log formatter extending LogFormatter, I guess...

I agree with @Tacsipacsi's explanation. See also T230749. IMO all that needs to be fixed is just the documentation for translators on translatewiki.net.

So what is the correct documentation?

The one that’s been in use for almost two years.

Glad to see no one upstreamed it.