Inconsistent or improvable language in UI in an effort to make voice and tone more consistent, clear, or appropriate.
See also:
This was caused by private WMF config added to mitigate email abuse (T341908). It has been removed now, as it was found to be no longer needed after discussion in the task (the abuse it protected against happened more than a year ago). Sending emails in this scenario should work again.
The other option would be to manually copy over the translations for each of the remaining 50 languages, either via Gerrit or via translatewiki.net.
Looks fixed by the patch.
Change #1050028 merged by jenkins-bot:
[mediawiki/extensions/MultimediaViewer@master] Rename whitelist to allowlist
The reason, as I understand it, is that some languages have more complicated plural rules than just one versus many.
c:Module:Self currently uses the following 4 messages:
When I look into the code of the AntiSpoof extension the only piece of code I can find that is directly related to renaming users is a DELETE. It deletes the old row with the old username from the spoofuser table. I can't find anything that looks like it would intentionally keep track of old usernames. Where does this code live? Or does this imply that the DELETE I found is broken and old usernames get blocked indefinitely by accident? Why does it show the new username then?
@thcipriani since the migration to GitLab seems to be postponed (indefinitely?) can we reopen this ticket?
Change #1050028 had a related patch set uploaded (by Simon04; author: Simon04):
[mediawiki/extensions/MultimediaViewer@master] Rename whitelist to allowlist
Change #1050025 had a related patch set uploaded (by Simon04; author: Simon04):
[mediawiki/extensions/UploadWizard@master] Rename blacklist to denylist
Based on this message to the list, it doesn't look like the migration to Gitlab is going to happen any time soon. Can we make this change independent of that migration?
All message issues are appropriate for I18n :)
not a translation issue
Yes, although it will take a few days or weeks until all pages are moved to the newly renamed tracking categories. This can be accelerated by purging them.
Is it enough to simply change the en.json messages and wait for the deployment train? Or does it also need some kind of cache refreshing?
Change #1042961 had a related patch set uploaded (by Aklapper; author: Skierpage):
[mediawiki/extensions/Score@master] i18n: improve score-use-category title text
I submitted gerrit change 1042961 for Extension score, before learning of this task.
@Jdforrester-WMF could we also update the i18n messages for the extension name without disruption? That would change what's displayed on Special:Version too.
That would be renaming the extension (or "forking" it and then moving to the new version), so that "Nuke" doesn't show up on Special:Version either, and documentation is listed under MassDelete, etc.
Good to know that the rename special page rename may get us 95% of the way there. Interested to know how the 5% that wouldn't be covered looks like
Reopening because Commons templates were never updated to use the new message.
For users' familiarity across wiki installations, I might prefer creating one single alternative name and setting a toggle so that wikis can config between the two. Then whichever one is not chosen redirects to the other.
@Jdforrester-WMF and @RheingoldRiver would using a special page alias that's configurable by communities, in a similar manner to the GrowthExperiments Extension work to allow some form of custom naming that would avoid the use of the work "Nuke"?
Renaming extensions is extremely difficult; in practice, this is "re-make the Nuke extension under another name, deploy both to production, then slowly move users over and phase out the old one". The effort may not be worth the benefit, though I see the point.