Wikimedia Bugzilla is closed!

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