Related T16649 (bug 14649) was fixed.

This task so far talks only about the directionality of a message; however, I imagine getting its language its also important, so we can set the correct lang attribute if necessary, e. g. for screenreaders. (For example, T32182: Untranslated gadget descriptions have incorrect directionality in RTL user languages was mostly fixed by applying dir="auto", but the language of untranslated gadget descriptions remains unchanged (i. e., the page content language, not the language of the message that was actually used)).

In T32238#5856019, @Lucas_Werkmeister_WMDE wrote:

This task so far talks only about the directionality of a message; however, I imagine getting its language its also important, so we can set the correct lang attribute if necessary, e. g. for screenreaders.

I was about to open a new task about getting the language. Should I create it, or should we repurpose this task to ask for the language instead of the text directionality? (If we have the language, querying the directionality is trivial, so I don’t see why a way to get just the directionality would make sense once querying the language is possible.)

@Tacsipacsi Where in the interface specifically are you observing this issue? I think the current task I opened in 2011 is too broad and should probably be closed in favour of more specific tasks for features/areas in the interface where missing translations are common. User-generated messages like Gadgets are as such possibly the only case, but there may be others. We could keep the task open for a future project to magically solve this for all interface messages everywhere, but I don't know how feasible this is given that in a lot of cases plain text is required/expected and additional HTML would thus violate the caller contract if it somehow were inserted by the Message class or otherwise. Hence it seems like something at least for the immediate future may be better addressed with more targetted solutions where it is most needed.

Probably the only areas that are especially problematic are those that are translated on-wiki (in addition to gadgets, the sidebar is what comes to my mind). Other than that, only specific (many!) languages are particularly affected, see for example the mediawiki.org main page in Kashmiri (Devanagari script)—there are more interface messages in Latin script (English) than in Devanagari (Kashmiri).

The idea came up in a thread of Id710e082982278d31058c28288da0a77b7253133, where we talked about the extension code’s inability to add proper markup. Also in T32238#7317220, I asked a way to query the language—which is opt-in by design—, not automatic markup (although that could be a plus that solves most cases less painfully, but more complicated ones like tooltip texts, input placeholders etc. would still need a directly query the language). Even if there’s automatic markup, of course it must be opt-in (maybe including a deprecation process to eventually force all code to explicitly indicate whether fallbacks should be marked up).

Magically solving this for all interface messages everywhere is a huge task and probably impossible in a short to medium term, but I think just making it possible to query the language and letting the calling code do whatever it wants with it, is well-scoped and doable (although not easy, especially in a performant way). If you feel better, I can open a new parent ticket about using this new functionality in Translate to mark up that particular message.

By the way, properly marking the language of parts of the page is a WCAG 2.1 AA-level success criterion, which is (as far as I remember) the minimum we want to achieve in terms of accessibility.

https://gerrit.wikimedia.org/r/c/mediawiki/core/+/72866 seems related to this task.