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:

1. core interface language preference;
2. 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".»;
3. userpage #babel, to absorb/deprecate Wikibase functionality;
4. Translate "assistant languagues" preference, as ULS does (optional);
5. other stuff possible in followups, e.g. taking from compact links suggestions and translator selection comments.