I made this a subtask of T279415 because it’s closely related, although strictly speaking here we’re using WikibaseClient’s UserLanguage service rather than WikibaseRepo’s. There’s no equivalent task for WikibaseClient, and it doesn’t seem worth creating one, because the SidebarLinkBadgeDisplay is actually the last service to use it AFAICT.

It’s also perhaps worth noting that, after a “normal” purge of commons:Category:A Study in Scarlet, the badge display is translated correctly when you load the page with ?uselang=de, ?uselang=zh etc. – so there’s some splitting of the parser cache going on, I think, but a purge with the wrong uselang can still break it.

The simplest way to solve this task would be to always use the site content language for the badge display, but then we’d break the mostly-working localization of this feature on Commons and other multilingual wikis.

I would believe displaying in user language is the expected/intended behavior.

Seems like caching-problem-only.

Change #1146644 had a related patch set uploaded (by Lucas Werkmeister (WMDE); author: Lucas Werkmeister (WMDE)):

[mediawiki/extensions/Wikibase@master] Remove WikibaseClient.UserLanguage service

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

Please note that the text still need to based on either user language or page view language, especially for zh Wikipedia.

The attached change shouldn’t have any effect, it just refactors the code so nothing else will start to use this deprecated service.

♥️

Change #1146644 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Remove WikibaseClient.UserLanguage service

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

With wgLang being on track for deprecation, this would need to be resolved, as we can not migrate to RequestContext here. Would it be possible that the users of this service specify the language instead?
Having no previous experience with Wikibase, I would like to avoid to get into this myself.

As far as I see, storing the labels in the parser output is only caching – the item IDs could be extracted and the labels translated post-cache, where we have access to an OutputPage object. Would that be too expensive without caching? If yes, maybe could we cache the labels separately in a per-language cache? Given that there’s only a handful of badges, it wouldn’t grow too big (on Wikidata, 13 badges × ~550 languages selectable in preferences = ~7100 entries in worst case, but probably way less).

This is now the only remaining read from wgLang in Wikimedia production. The solution by Tacsipasci sounds reasonable to me, but ultimately I do not feel knowledgeable enough to make it happen.

In T344050#11748895, @MGChecker wrote:

With wgLang being on track for deprecation, this would need to be resolved, as we can not migrate to RequestContext here. Would it be possible that the users of this service specify the language instead?

In principle, that’s usually the way to go with these tasks. I feel like I must have looked into it when I created this task, but I’m not sure why I didn’t go for it; to me it looks like it should be possible to do this: all the callers of SidebarLinkBadgeDisplay have a parser output or output page relatively available, as far as I can tell, and should be able to use the language of that parser output or output page.

• SidebarLinkBadgeDisplay::getBadgeInfo() called from
  • LanguageLinkBadgeDisplay::attachBadgesToOutput(), has a ParserOutput which provides getLanguage() (returns Bcp47Code)
  • OtherProjectsSidebarGenerator::buildSidebarLink(), called by buildPreliminarySidebarFromSiteLinks() in the same method, called by
    • OtherProjectsSidebarGenerator::buildProjectLinkSidebarFromItemId(), called by
      • AboutTopicRenderer::setOtherProjectsLinks() (ArticlePlaceholder), has an OutputPage which provides getLanguage() (returns Language) and getLanguageCode() (returns Bcp47Code)
    • OtherProjectsSidebarGenerator::buildProjectLinkSidebar(), called by
      • ClientParserOutputDataUpdater::updateOtherProjectsLinksData(), has a ParserOutputProvider from which we can get a ParserOutput

In T344050#11833775, @Lucas_Werkmeister_WMDE wrote:

to me it looks like it should be possible to do this: all the callers of SidebarLinkBadgeDisplay have a parser output or output page relatively available, as far as I can tell, and should be able to use the language of that parser output or output page.

Because the tooltips use the UI language, not the content language – which makes sense given that they’re shown as part of the interface, not directly in the parser output. The parser output language is the content language, not the user language. OutputPage::getLanguage() returns the UI language, but it’s not available everywhere (and should not be used in anything that goes into the parser cache, as that would not fix the cache pollution issue the current task is originally about).

Change #1278478 had a related patch set uploaded (by MGChecker; author: MGChecker):

[mediawiki/extensions/Wikibase@master] Avoid use of deprecated wgLang in Wikibase

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

If one points me to an instance where similar caching is done, I might as well give it a shot.