Lucas_Werkmeister_WMDE added a comment.
Okay, I think I’ve found the two code paths that do subtly different things
here.
- “Server-side order” (initial rendering):
-
`OutputPageBeforeHTMLHookHandler::getLocallyRenderedEntityViewPlaceholderExpander()`
calls `$this->userPreferredTermsLanguages->getLanguages( $language->getCode(),
$user )` (where `$language` is the UI language)
- `UserPreferredContentLanguagesLookup::getLanguages()` calls
`$this->userLanguageLookup->getAllUserLanguages( $user )` and then prepends the
request UI language to it
- `BabelUserLanguageLookup::getAllUserLanguages()` calls
`$this->getUserSpecifiedLanguages( $user )` (the user’s Babel languages) and
prepends the user’s UI language //option// to it
- final order: request UI language (uselang URL parameter), user UI
language (option), user Babel languages
- “Client-side order” (after reordering) – actually, this is also largely
controlled by the server:
- `wikibase.getUserLanguages()` gets `mw.config.get( 'wgUserLanguage' )`
and prepends the request UI language to it
- the `wgUserLanguage` config had been added in
`OutputPageBeforeHTMLHookHandler::addJsUserLanguages()` (same hook handler
class as above)
- `OutputPageBeforeHTMLHookHandler::addJsUserLanguages()` calls
`$this->userLanguageLookup->getUserSpecifiedLanguages( $out->getUser() )` (same
user language lookup service as above)
- `BabelUserLanguageLookup::getUserSpecifiedLanguages()` returns the user’s
Babel languages
- final order: request UI language (uselang URL parameter), user Babel
languages
- (Both also limit the returned language codes to only ones that are actually
valid term language codes, and ensure that language codes aren’t listed twice,
but that’s not important here.)
So in both cases we ultimately start with the request UI language and end
with the user Babel languages, but the initial server-rendered termbox also
includes the user’s language //preference// (aka option, setting, whatever)
before all other Babel languages, whereas the JS code uses an order where the
user’s language preference isn’t used (it appears wherever the user has
included it in their Babel, if at all).
I think that including the user language preference in addition to the
request UI language probably makes sense (someone will have written that code
for a reason). I don’t think there’s a good reason why we shouldn’t send that
same language list to the JS side, so we probably just want to make
`OutputPageBeforeHTMLHookHandler::addJsUserLanguages()` call
`$this->userPreferredTermsLanguages->getLanguages( $language->getCode(), $user
)` as well.
TASK DETAIL
https://phabricator.wikimedia.org/T311617
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Lucas_Werkmeister_WMDE
Cc: Manuel, Lydia_Pintscher, Aklapper, Lucas_Werkmeister_WMDE, Astuthiodit_1,
karapayneWMDE, Invadibot, maantietaja, ItamarWMDE, Akuckartz, Nandana, Lahi,
Gq86, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS,
Wikidata-bugs, aude, Mbch331
_______________________________________________
Wikidata-bugs mailing list -- [email protected]
To unsubscribe send an email to [email protected]
