As a researcher or sysadmin, I want to run server-side scripts which take into account the language probably spoken by my users, so that I can reach them most effectively.
As an extension or script author, I want to provide a meaningful language selection to the users of my product without adding a new selection method, so that the users have a predictable experience and there is less technical debt and fatigue for everyone.
ULS is the most sensible place where to place such an API; it could then fetch the information from various sources including core and extensions. Initially, users would only be able to see language information about themselves.
Sources of the information:
- core interface language preference;
- guesses routinely used by ULS, e.g. based on CLDR language-territory: «leila> This is santhosh's response from another thread on the topic of ULS: "For logged in users, the preferences are stored in user_properties table with key 'uls-preferences'. The preferences is a json serialized data with language preferences: previous language choices, input method preferences etc. For anon users, we store this in localstorage at browser; that is not useful much".»;
- userpage #babel, to absorb/deprecate Wikibase functionality;
- Translate "assistant languagues" preference, as ULS does (optional);
- other stuff possible in followups, e.g. taking from compact links suggestions and translator selection comments.