Task Breakdown Notes:

Update: The task description has changed since writing this comment

@Manuel we have a few questions and clarifications, with some confusion in particular regarding the first acceptance criteria:

• Since we are not changing edit mode after all, do we just ignore aliases in this case then?
• We are still very unclear about the scope of these tasks, and the preceding task (T329655) in the v0.4 milestone for MUL:
  • Is the user going to be given control over the ultimate fallback language?
  • If not, does it even make sense to start with MUL labels as placeholder given that this task is the end goal?
• This may be mitigated by trimming the description of the task a little

See T329655#8922650 and T329655#8958191 for some initial investigation into this (though the situation changes a bit now that we want to include general language fallbacks, not just the mul label, as the placeholder).

Change 938239 had a related patch set uploaded (by Michael Große; author: Michael Große):

[mediawiki/extensions/Wikibase@master] Use fallback chain for label placeholders

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

Change 938285 had a related patch set uploaded (by Michael Große; author: Michael Große):

[mediawiki/extensions/Wikibase@master] Set entity labels in ParserOutput to show as fallback

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

Change 938872 had a related patch set uploaded (by Michael Große; author: Michael Große):

[mediawiki/extensions/Wikibase@master] [DNM]: Show label placeholders with fallback labels in ULS and all languages

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

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

[mediawiki/core@master] POC: Create Language objects without initializing l10n cache

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

Change 938239 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Use fallback chain for label placeholders in legacy termbox

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

Change 938285 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Set entity labels in ParserOutput to show as fallback in termbox

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

@Manuel You can now test the first 2/3rd of this on beta, for example here: https://wikidata.beta.wmflabs.org/wiki/Q522693

Note that you may have to purge or edit an Item or Property to see the effect.

@Michael, thank you, this was very helpful! Some things that I noticed:

1. It only works for all the languages where I added Babels (plus for my UI language):

When I just tried it without setting my Babels up, I only had empty fallbacks. I understand why (ULS), but I realize that this will make it a bit challenging for the community to test this functionality. You mentioned that the solution for "In all languages" would also solve ULS fallback. Did you find an elegant solution for this by any chance? To get a better testing experience, I am now considering non-elegant solutions as well (e.g. adding API calls for the missing fallbacks). Would this be an easy thing to do?

2. Also, if I click on "All entered languages", "multiple languages" is not the last language on the list anymore:

In T340832#9034335, @Manuel wrote:

@Michael, thank you, this was very helpful! Some things that I noticed:

1. It only works for all the languages where I added Babels (plus for my UI language):

When I just tried it without setting my Babels up, I only had empty fallbacks. I understand why (ULS), but I realize that this will make it a bit challenging for the community to test this functionality. You mentioned that the solution for "In all languages" would also solve ULS fallback. Did you find an elegant solution for this by any chance?

We're working on that. That is the reason I called it "the first 2/3 being available to test" because the last third is still in doing. As is this task ;).

2. Also, if I click on "All entered languages", "multiple languages" is not the last language on the list anymore:

Yes, that is already the current behavior and was not touched here. See for example https://test.wikidata.org/wiki/Q170130
(Though, to be honest, your statement seems to imply that this might not be desired? I'm not sure if the alternative - languages switching places - is actually any better.)

We're working on that.

That is great news, thank you! \o/

Yes, that is already the current behavior

Ah okay, good to know! I have discussed this with @Sarai-WMDE, and this is in deed as expected. Thank you for the explanation!

Change 940158 abandoned by Lucas Werkmeister (WMDE):

[mediawiki/core@master] POC: Create Language objects without initializing l10n cache

Reason:

superseded by the other changes attached to T342418, especially I7ec2d87c0f

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

Change 938872 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Show label placeholders with fallback labels in ULS and all languages

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

If you're logged out (for example in a private window), then you should now be able to see the label fallback also for languages added by ULS as well as those behind "All entered languages" on beta, for example this Item: https://wikidata.beta.wmflabs.org/wiki/Q522693

Yes, it's working on Beta, if I am not logged-in! :)

I cannot log in for some reason, but I guess that this is unrelated:

[ZMtSxxeNP58GM1AG4gbcxwAAAA0] /w/index.php?returnto=Wikidata:Main+Page&title=Special:UserLogin RuntimeException: Failed to run getConfiguration.php: No MWMultiVersion instance initialized! MWScript.php wrapper not used?
Backtrace:

from /srv/mediawiki/php-master/includes/SiteConfiguration.php(608)
#0 /srv/mediawiki/php-master/includes/jobqueue/JobQueueGroupFactory.php(115): SiteConfiguration->getConfig(string, array)
#1 /srv/mediawiki/php-master/includes/libs/objectcache/wancache/WANObjectCache.php(1725): MediaWiki\JobQueue\JobQueueGroupFactory::MediaWiki\JobQueue\{closure}(boolean, integer, array, NULL, array)
#2 /srv/mediawiki/php-master/includes/libs/objectcache/wancache/WANObjectCache.php(1555): WANObjectCache->fetchOrRegenerate(string, integer, Closure, array, array)
#3 /srv/mediawiki/php-master/includes/jobqueue/JobQueueGroupFactory.php(117): WANObjectCache->getWithSetCallback(string, integer, Closure, array)
(...)

I cannot log in for some reason, but I guess that this is unrelated:

Yes, that seems to be T343291: [betacluster] Cannot login - UserLogin RuntimeException: Failed to run getConfiguration.php.

But the MediaWiki core changes that were needed for this still seems to have broken things: T343375: Translation of some key namespaces ("Module:", others?) missing from 1.41.0-wmf.20, breaking any hewiki page that uses that. The train was rolled back, and the core change that this work relies on was reverted. So this not really done yet after all. :/

In Show label placeholders with fallback labels in ULS and all languages (I61f7fea0) we added some performance tracking for the load that creating the fallback-chains will put on the startup.js script. We used the metric name wikibase.view.fallbackchains.timing. Once this change is available on test.wikidata.org, we should also create a Grafana dashboard/panel for this metric.

Then we can use the incoming data to form a better opinion on whether the current approach is sustainable.

We have now metrics for our wikibase.fallbackchain RL module incoming: https://grafana.wikimedia.org/d/JaC2imRIk/wikidata-internal-performance-monitoring
What graphs do we want to see here in detail? Currently it is showing the 99th percentile.

@Manuel Product-wise all the features should now be live and be ready to be verified. Only in peer review for thoughts on the above.

This one is also working greatl, thank you, @Michael! \o/

Regarding the dashboard, I’m quite surprised that there are about a dozen data points per minute, and that it’s a fairly steady rate over time:

Wouldn’t we expect big spikes after each deployment (restarting php-fpm and thus clearing the local server object cache) and otherwise nothing (until TTL_WEEK expires)?

The only explanation I can think of is that it takes relatively long for any individual app server to receive a request for (test)wikidatawiki after a restart, which would spread out the spike. But I’m not sure that checks out.

There is a big spike starting around 18:08 UTC yesterday, which matches well enough with 18:19 group1 wikis to 1.41.0-wmf.23 (that log message marks the end of the deployment), but nothing comparable for the other deployments since then which should also have restarted php-fpm.

Can't explain that particular spike, but my recollection on this is pretty hazy and I don't have the code in front of me, but doesn't startup.js always evaluate the code of the module in order to detect changes?

But if what I wrote above were actually the case, wouldn't we see orders of magnitude more events? 🤔

Could you add that panel for .count to the dashboard?

In T340832#9117490, @Michael wrote:

Can't explain that particular spike, but my recollection on this is pretty hazy and I don't have the code in front of me, but doesn't startup.js always evaluate the code of the module in order to detect changes?

But if what I wrote above were actually the case, wouldn't we see orders of magnitude more events? 🤔

We’re only tracking the timing inside the cache callback, so we’re only seeing cache misses.

Could you add that panel for .count to the dashboard?

Done.

Wait, I was looking at the wrong metric! I assumed the dashboard used wikibase.view.fallbackchains.timing (our custom metric), but it actually uses resourceloader_build.wikibase_fallbackchains, which is tracked by ResourceLoader and covers all module loads regardless of the cache.

I fixed the dashboard, and now I think it makes much more sense: cache misses are rare, and the uncached time to create the module is in the tens of milliseconds instead of 0.1 (which is in fact the time to get it from the cache).

Thanks! I've added the annotations for deployments (both in general and a separate one for only the train).

However, I'm confused by what looks to me like a mismatch between the two rows of graphs. For example when zooming in to an instance at the beginning of our data: https://grafana.wikimedia.org/d/JaC2imRIk/wikidata-internal-performance-monitoring?orgId=1&forceLogin=&from=1692194489075&to=1692194821065
This shows four requests to that module, all four had a cache miss. Should not now also the "Contribution to startup.js by the wikibase.fallbackchains RL module" show a time that is in the two- to three-digit milliseconds range? Now I'm wondering if that particular metric actually gets executed during startup.js, or maybe if it gets executed when the module is actually requested? (And thus is much more likely to hit a server that sees it already as cached.)

Apparently the metric is only tracked when the actual module is loaded, not in startup. Also, I get the same weird timing locally:

MediaWiki.wikibase.view.fallbackchains.timing:313.77077102661|ms
MediaWiki.resourceloader_build.all:0.76603889465332|ms
MediaWiki.resourceloader_build.wikibase_fallbackchains:0.76603889465332|ms

And I think I’ve figured out why: it’s because the fallback chains are already put together and hashed to determine the version, which happens much earlier – if you go very far up the call stack:

		// Combine versions to propagate cache invalidation
		$versionHash = $this->getCombinedVersion( $context, array_keys( $modules ) );

		// See RFC 2616 § 3.11 Entity Tags
		// https://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.11
		$etag = 'W/"' . $versionHash . '"';

		// Try the client-side cache first
		if ( $this->tryRespondNotModified( $context, $etag ) ) {
			return; // output handled (buffers cleared)
		}

		// Generate a response
		$response = $this->makeModuleResponse( $context, $modules, $missing );

getCombinedVersion() is where we already generate the fallback chains; makeModuleResponse() is where RL eventually does the timing, by which point we’ve already assembled all the data. (Our callback won’t even be called a second time, RL caches it in FileModule’s $this->expandedPackageFiles.)

I wonder if there’s a cheaper version hash we can provide with the same semantics (cleared on each deployment / php-fpm restart). Is there something like a php-fpm version number or process ID?

I wonder if there’s a cheaper version hash we can provide with the same semantics (cleared on each deployment / php-fpm restart). Is there something like a php-fpm version number or process ID?

Nah, on second thought, that probably wouldn’t be a good idea.

I think we should just live with the fact that the basic RL metrics aren’t very informative in this case. We have some better tracking for the timing, and its results look decent enough, IMHO; I just added some fields to the legend, and it looks like there were 364 total cache misses the past 7 days, for a total of ca. 14.8 s. (I think the total time is slightly undercounting due to a bit of aggregation, but not by much.)

Sounds good to me. So since Product already gave their ok in T340832#9096600, I think this subtask can be closed and moved to done? We can have another look at the stats once it gets enabled in production, I guess.