Some discussion about loading all the languages objects on the server. Mapping [code]-> [zid]
Discussion ongoing whether we should keep it at all and that we can’t use this in abstract mode.
The server-side languages map is currently responsible for:
- ZMultilingualStringDialog: use server-side language mapping to get language labels
This is needed to comply with Wikidata language lists where a literal language is used instead of a ZID.
Now we can render a list with human readable language labels instead of ISO codes.
- Make sure the fallbackLanguage chain is resolved to ZIDs before loading the app.
Geno mentioned we might not need #1 for Abstract, but we do need #2 for Abstract because I am using the fallback languages to determine which language to load in the second preview block. Also the cdx-lookup does not like it if it gets initialized with english and then a render later it becomes the zid of dutch. This causes bugs in the lookup where the suggestions don’t show when clearing the input. This can be hacked around using a :key prop with the language.
Server-side Code from ZobjectContentHandler.php:
// Add language mapping for multilingual string dialog $parserOutput->setJsConfigVar( 'wgWikiLambdaLangs', $this->zObjectStore->fetchAllZLanguageObjects() );
Implementation details:
- getLanguageZidOfCode (library.js) only checks state.languages and wgWikiLambdaLangs. Codes not in either return undefined.
- getFallbackLanguageZids (languages.js) maps mw.language.getFallbackLanguageChain() through getLanguageZidOfCode and filters to truthy. So codes that were never fetched yield missing ZIDs (empty or partial list).
- Consumers that need those ZIDs:
- getDefaultPreviewLanguageZids in abstractWiki.js — used in initializeAbstractWikiContent to set previewLanguageZids; needs fallback ZIDs to be available at init time. (new code WIP)
- ZMultilingualString.vue — allViewItems (line ~160), initializeMultilingualStringList (getFallbackLanguageZids), and watch(langs) (lines ~424–425) all rely on getLanguageZidOfCode; ZIDs must eventually be available so UI shows ZIDs and priority works. (now handled by server-side language map)
Alternative solution implemented currently
In https://phabricator.wikimedia.org/T411703 This issue is addressed by adding store.ensureLanguageCodes( { codes } );.
It fetches the zids for the language codes and then runs fetchZids to fetch the objects of those language zids to ensure label data.
This seems to work well for Abstract and for the ZMultilingualString we can do this aswell and therefor the server-map does not seem to be neccessary anymore. Should we remove it and make @Jdforrester-WMF happy?