Bryan, Niklas, Sam: I have no idea how the l10n cache works. The Jenkins job https://integration.wikimedia.org/ci/job/beta-code-update/ does generate the l10n cache using cdb at "/a/common/php-master/cache/l10n/l10n_cache-ab.cdb"

Maybe a configuration setting is missing?

Based on CommonSettings.php, the config is unconditional:

$wgLocalisationCacheConf['storeDirectory'] = "$IP/cache/l10n";
$wgLocalisationCacheConf['manualRecache'] = true;

Doesn't seem to be overridden in the labs configs. Which would suggest labs is using it...

production:

reedy@tin:~$ mwscript eval.php enwiki

var_dump( $wgLocalisationCacheConf );

array(5) {

["class"]=>
string(17) "LocalisationCache"
["store"]=>
string(6) "detect"
["storeClass"]=>
bool(false)
["storeDirectory"]=>
string(34) "/a/common/php-1.23wmf18/cache/l10n"
["manualRecache"]=>
bool(true)

}

beta:

reedy@deployment-bastion:~$ mwscript eval.php enwiki

var_dump( $wgLocalisationCacheConf );

array(5) {

["class"]=>
string(17) "LocalisationCache"
["store"]=>
string(6) "detect"
["storeClass"]=>
bool(false)
["storeDirectory"]=>
string(55) "/data/project/apache/common-local/php-master/cache/l10n"
["manualRecache"]=>
bool(true)

}

Bar path (which is very much to be expected), this would look to be identical

(In reply to Sam Reed (reedy) from comment #3)

Bar path (which is very much to be expected), this would look to be identical

Sounds like I was talking out of the wrong side of my head then. That's what I get for not checking before I yammered.

For what it is worth, I noticed a few hours ago that the l10n cache directory on beta belonged to the wrong user (we migrated l10nupdate to be in LDAP instead of local to the instance).

I fixed up /data/project/apache/common-local/php-master/cache/l10n by running chown -R l10nupdate:l10nupdate

Bryan > should we just close this bug?

/me does that for him