Move `getLanguageFallbackChainFactory` from `GenericServices`
Closed, InvalidPublic
Actions

Assigned To

Authored By

	ItamarWMDE
	Aug 14 2020, 1:02 PM

Description

As already noted in T259783 this service is not generic, as it should rely on the wiki's content language, and therefore should be moved to SingleEntitySourceServices and MultipleEntitySourceServices or a more appropriate commonplace.

Service added to SingleEntitySourceServices
Service added to MultipleEntitySourceServices
GenericServices LanguageFallbackChainFactory should not be used & should be removed.

This may end up fixing some or all of T259783: LanguageFallbackChain does not end in 'en' for language codes that are not a valid format (currently in the backlog)

Details

	Subject	Repo	Branch	Lines +/-
	Inject MediaWiki language services into LanguageFallbackChainFactory	mediawiki/extensions/Wikibase	master	+42 -35

Customize query in gerrit

Related Objects
Search...

		Status	Subtype	Assigned	Task
		Invalid		None	T205268 Many services in GenericServices are not actually that generic.
		Invalid		WMDE-leszek	T260431 Move `getLanguageFallbackChainFactory` from `GenericServices`

Event Timeline

ItamarWMDE created this task.Aug 14 2020, 1:02 PM

ItamarWMDE mentioned this in T260163: Investigate which of the GenericServices are actually generic vs those that are not.

Maintenance_bot moved this task from incoming to in progress on the Wikidata board.Aug 14 2020, 1:15 PM

ItamarWMDE removed ItamarWMDE as the assignee of this task.Aug 14 2020, 1:25 PM

ItamarWMDE removed projects: Story, Wikidata-Campsite (Wikidata-Campsite-Iteration-∞ (On Hold)), User-Addshore, Wikidata-Trailblazing-Exploration.Aug 14 2020, 1:28 PM

Addshore added a project: Wikidata-Campsite (Wikidata-Campsite-Iteration-∞ (On Hold)).Aug 17 2020, 9:25 AM

Addshore renamed this task from Move `getLanguageFallbackChain` from `GenericServices` to Move `getLanguageFallbackChainFactory` from `GenericServices`.Aug 17 2020, 9:34 AM

Addshore updated the task description. (Show Details)

Lucas_Werkmeister_WMDE claimed this task.Aug 17 2020, 11:15 AM

Lucas_Werkmeister_WMDE moved this task from To Do (prioritised from top to bottom) to Doing on the Wikidata-Campsite (Wikidata-Campsite-Iteration-∞ (On Hold)) board.

Change 620689 had a related patch set uploaded (by Lucas Werkmeister (WMDE); owner: Lucas Werkmeister (WMDE)):
[mediawiki/extensions/Wikibase@master] Inject MediaWiki language services into LanguageFallbackChainFactory

https://gerrit.wikimedia.org/r/620689

gerritbot added a project: Patch-For-Review.Aug 17 2020, 11:16 AM

Change 620689 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Inject MediaWiki language services into LanguageFallbackChainFactory

https://gerrit.wikimedia.org/r/620689

ReleaseTaggerBot added a project: MW-1.36-notes (1.36.0-wmf.5; 2020-08-18).Aug 17 2020, 2:00 PM

Maintenance_bot removed a project: Patch-For-Review.Aug 17 2020, 2:10 PM

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:

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.
The final fallback language, hard-coded to 'en' in 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 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.)