Totally agreed we need a way to make such mistakes less frequent. Thanks for writing this up. :-)

A warning should be raised when two keys have the same value.

There'll be a bunch of false positives (just in English in core, there are three i18n messages defined as '"Edit"': edit, skin-view-edit, and restriction-edit), so warning not error seems OK, but…

Where should said warning be raised?

Banana-checker could check this, with an allow-list for expected collisions on a per-language basis(?!), but i18n update commits bypass CI anyway. Should it block CI so the next time someone commits there they find the issue?

Inside the Translate/TWN on-wiki interface? But then if translators are allowed to proceed anyway, that doesn't necessarily fix things (banner blindness means any warning is generally ignored, especially by power-users who "know" what they're doing). And if they're not, we'll need to re-word values that currently clash to different labels?

This is mostly an issue for log names; maybe for the meantime we should add a special template to the qqqs of those on TWN saying that they must be unique in this language across core and all extensions that might be co-installed?

I suggest placing the check and warning in \LogEventsList::getTypeMenuDesc. I think that has the highest benefit / effort ratio without false positives.

What I was intending was a logstash warning/error which is used to indicate a duplicate value for the the translation. There would be nothing in CI because as you say translation commits bypass it.

Ideally this would then allow someone to find the issue via logstash and not after a few years of the duplicate translation existing.

In T360326#9641275, @Dreamy_Jazz wrote:

What I was intending was a logstash warning/error which is used to indicate a duplicate value for the the translation. There would be nothing in CI because as you say translation commits bypass it.

Ideally this would then allow someone to find the issue via logstash and not after a few years of the duplicate translation existing.

That sounds like a good plan, yes. Happy to help if needed.

Change #1013374 had a related patch set uploaded (by Dreamy Jazz; author: Dreamy Jazz):

[mediawiki/core@master] Warn if HTMLFormField on duplicate translations of options-messages

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

I noted this as a risky change at T360157#9677661, just in case.

Change #1013374 merged by jenkins-bot:

[mediawiki/core@master] Log duplicate translations of options-messages for HTMLFormField

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