Lucas_Werkmeister_WMDE added a comment.
I think the current status of this task is that it’s completely unclear how it should be resolved. I’ll try to summarize. There seem to be two potential sources of non-genericness in this service: 1. The list of allowed / known language codes can vary by entity source, or indeed even by entity //type//. For instance, both Items and Lexemes may come from the same entity source (Wikidata), and yet Lexemes allow for some additional language codes that are not supported in Items. 2. The final fallback language, hard-coded to `'en'` in T259783 <https://phabricator.wikimedia.org/T259783>, should maybe be the content language of the entity source wiki. Neither a `LanguageFallbackChainFactory` nor a `TermLanguageFallbackChain` currently come into much contact with an entity source, entity type, or entity ID. This makes them unlike many other services in `MultipleEntitySourceServices`, which often receive an entity ID as input and dispatch to the correct single entity source service based on it. At the same time, it seems that even an individual `TermLanguageFallbackChain` is currently often used with entities of different types. Neither of the two sources of non-genericness mentioned above is very much related to the `LanguageFallbackChainFactory`, which is rather concerned with looking up language codes and dealing with variants. It seems possible to leave `LanguageFallbackChainFactory` completely agnostic of entity sources, but instead make it create `TermLanguageFallbackChain` objects that directly wrap a chain of languages (with no filtering at construction time), and then later both the allowed / known language codes and the final fallback language are provided (possibly as part of the same object, by adding the final fallback language to the `ContentLanguages` interface) whenever a `TermLanguageFallbackChain` is used (e. g. `$chain->getFetchLanguageCodes( $contentLanguages )`). But that wouldn’t really fit into `MultipleEntitySourceServices` at all. Finally, I wonder if the list of allowed / known language codes should be related to the entity source at all. Additional term languages used to be defined in site config, but for T260118 <https://phabricator.wikimedia.org/T260118> we moved them into the Wikibase code. Defining additional term languages via `$wgExtraLanguageNames` still works, but we could say that it’s no longer really supported by Wikibase, and that the supported language codes for a certain entity type are always the same. (See also T220798 <https://phabricator.wikimedia.org/T220798>.) TASK DETAIL https://phabricator.wikimedia.org/T260431 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Lucas_Werkmeister_WMDE Cc: Aklapper, Addshore, WMDE-leszek, ItamarWMDE, Akuckartz, Iflorez, darthmon_wmde, alaa_wmde, DannyS712, Nandana, Lahi, Gq86, Pablo-WMDE, GoranSMilovanovic, QZanden, LawExplorer, _jensen, rosalieper, Scott_WUaS, Jonas, Izno, Wikidata-bugs, aude, Dinoguy1000, Lydia_Pintscher, Mbch331, Jay8g
_______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
