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.