@Teslaton Would you mind providing some additional use cases for this, besides UI translators?

@Dbrant There are cases, where non-english users tend to (or have to) keep default english system-wide locale:

• corporate policy / locked settings
• wrong quality system localization (for their native language)
• wrong quality UI localization or a malfunction of some key app (which, too, does not provide independent UI lang switching...)

BUT at the same time would prefer some other Wikipedia-Android app locale, if available.

Also the contrary may occur (someome forced to use non-english system locale for any reason, but still prefers default english UI of Wikipedia-Android).

@Teslaton, hello! I was hoping to get a little more clarity on this card. Currently, we have three language inputs:

1. System language. This affects the UI language for most of the app (as well as the rest of the system). This is the canonical way to support additional locales in Android.
2. App language. Many apps support a language independent of the system. For the Wikipedia app, this is the default language used and affects the search and only certain UI elements like the article table of contents.
3. Article language. Many articles are available in multiple languages. This settings affects the current article language (and links appearing in the article often point to other articles in that language).

Three languages options... This is already confusing! :) I think your request is to make #2 more robust to affect _all_ UI elements. Is this correct or were you thinking of a fourth language option?

@Niedzielski wrote:

I think your request is to make #2 more robust to affect _all_ UI elements. Is this correct or were you thinking of a fourth language option?

Yes, that is precisely it. I would have imagined the separate cfg. option (enum) "Application language", with items being "(system default)", "Lang 1", "Lang 2", ... After changing the value from "(system default)" to some particular language, ALL app UI labels and messages would appear in that language, regardless of a system language.

Is that something, that is possible/easy-enough to implement? (I don't know much about Android app architecture and I18N practices in that ecosystem).

An almost identical task, T70299: Allow change of interface language, was declined by me a while back because it was determined that the additional complexity and required work was not worth the proposed benefits for the small segment of the user base that would likely use this feature. I'm not necessarily saying this task should be declined (something might have changed since then), but it's worth bearing in mind when this task is evaluated.

Hm, I wonder if this infrastructure would help our dark and light mode transitions too (also, probably a small audience)? I helped implement something similar for app themeing in another app. We registered and unregistered Views to an event bus in their onAttach / onDetach callbacks. It seemed to work well but maybe there's a better way.

My personal opinion is that I would love for our app language to work independently of the system language. However, Deskana is right, we'll have to weigh it against other features and prioritize appropriately.