Last modified: 2014-03-03 20:29:59 UTC
If a person is editing on meta or another multilingual wiki, they shouldn't have to go to Bing or Google translator or some such to try and figure out why they were blocked. Block reasons should be internationalized and the user should see the reason that they were blocked in the language they have choosen. Bug 61942 leads me to believe this is possible.
That would be possible if block reasons in the drop-down would be references to pages in the MediaWiki: namespace (interface messages), something like how MediaWiki:Sidebar works[1]: if a interface message with that name exists, use it in the user interface language, otherwise display it as it was entered. This should be done in the drop-down itself (allowing sysops to see the block reasons in their own language) and also when displaying the block reason to the user. ---- [1] https://www.mediawiki.org/wiki/Manual:Interface/Sidebar#Translations
That's basically what I was thinking.
As currently summarised, this bug is not quite valid: at most one can localise dropdown options and I see no reason why one would not use whatever is the "working language" of the wiki (who will review blocks if reasons are in another language?). Maybe what's missing here is the ability to transclude templates or parse the int magic word? Those could maybe added to the special parsing rules of edit summaries/log reasons.
(In reply to Nemo from comment #3) > As currently summarised, this bug is not quite valid: at most one can > localise dropdown options and I see no reason why one would not use whatever > is the "working language" of the wiki (who will review blocks if reasons are > in another language?). The bug is perfectly valid since it would allow: * Sysop that is performing the block would see the block reasons in the drop-down in his/her preferred language. * Blocked user receiving the notification about being blocked would see the block reason in his/her preferred language. * Any user looking at the block logs would see the block reason in his/her preferred language. Of course, manually entering a block reason wouldn't allow that, unless it matches an existing interface message. The only problem I would see is if any custom message clashes with an existing interface message.
