Page MenuHomePhabricator

Allow UI language selection via settings (in addition to content language selector)
Closed, DeclinedPublic

Description

Please correct me if I'm wrong, but there seems to be no straightforward way to choose app UI language (without system-wide language change).

I think simple UI lang switching would be useful both for readers and UI translators, I can imagine many use cases, when user wants to have app in some language but intentionally doesn't want to alter system-wide preferences.

Event Timeline

Teslaton updated the task description. (Show Details)
Teslaton raised the priority of this task from to Needs Triage.
Teslaton added a subscriber: Teslaton.
Restricted Application added subscribers: StudiesWorld, Aklapper. · View Herald TranscriptNov 28 2015, 10:05 PM
Dbrant added a subscriber: Dbrant.Nov 30 2015, 3:58 PM

@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).

Dbrant triaged this task as Lowest priority.

@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.

RHo closed this task as Declined.Mar 26 2018, 5:25 PM
RHo added a subscriber: RHo.

Declining as we will continue to use the system language for UI language in keeping with standard app behavior.
However, please note that work as part of T160567 will allow multiple Wikipedia languages to be set in the app without disrupting the system language set which hopefully address the spirit in which this task was created.