I added this as a subtask of T424265 for obvious reasons, but I suspect that alone might not be the sole instance of this issue. Labels displaying on that page is what is presently deployed on the website; while reading, the label is not displayed, so I can assume T423651 is still in the process of being deployed.

The other area where labels are displayed, recent changes, has this issue as well.

I'm led to believe AbstractContentUtils::resolveAbstractLabel does not properly handle the case where an en label does not exist, but a mul label does. That in mind, I'm going to move this to a child of T423649 since this seems to be a general issue. Someone more qualified than me can move it somewhere else if need be of course (or just get rid of the task relation altogether—I'm new here so I'm not sure how appropriate it is).

/includes/AbstractContent/AbstractContentUtils.php L101–105:

try {
	return $wbEntity->getLabels()->getByLanguage( $langCode )?->getText();
} catch ( OutOfBoundsException ) {
	return null;
}

So I don't really know PHP that well nor am I familiar with the WikiLambda codebase at all, but this seems to be the issue. My (clueless) guess as to how this could be fixed would be:

$wbLabels = $wbEntity->getLabels();
$wbLabel = $wbLabels->getByLanguage( $langCode );
if ( !$wbLabel ) {
	$wbLabel = $wbLabels->getByLanguage( "mul" );
}
return $wbLabel?->getText();

Although generally I think it would be better to work out some form of generalized fallback. For example if we want a zh-hant label specifically we should know to look for a more general zh label if it's not there and then fallback to mul if all else fails.

(Code pointer: the Wikibase code for this is in LanguageFallbackChainFactory, which builds a chain out of fallback languages, LanguageConverter variants, mul, and en. I don’t know if it would be feasible for WikiLambda to reuse this code, but in principle it would be good to support all the same fallbacks.)

We can't immediately use Wikibase's fallback factory for this, sadly, as we're dealing with non-Wikidata items in many places, but we should have a single place for this code at our end, at least.

Will beging by identifying the places (in our WL code) where lang fallback is currently handled ad hoc. I can push up draft on a utility class we can route everything through

Change #1298172 had a related patch set uploaded (by Ecarg; author: Ecarg):

[mediawiki/extensions/WikiLambda@master] Centralize `mul` language fallback logic

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

Change #1298172 merged by jenkins-bot:

[mediawiki/extensions/WikiLambda@master] abstract: Centralize `mul` language fallback logic

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