If the cache is cleared during certain high traffic scenarios there can be a race condition where if ( eZTranslationCache::canRestoreCache( $contextName, $tsTimeStamp ) ) fails as the file doesn't exists yet (it calls file_exists()). (See PR for context).

This leads the cache load for the context to fail and the cache remains empty. This in turns causes the translation to fall back to english and calls to i18n() gets inlined in the compiled template as english instead of the original language. Should affect most versions of legacy eZ Publish.

PR: https://github.com/ezsystems/ezpublish-legacy/pull/1388

Steps to reproduce:

• Set up a site access with a different language than default eng-GB. For example nor-NO.
• Ensure a page, such as / displays one or more translated strings via i18n operator. The more the better, especially with different translation contexts as each context has its own cache file.
• Hammer the site with traffic. I used ab -n10000 -c50 http://<site url>. A different set of parameters might be needed depending on hardware. I tried initially with -c20, but failed to reproduce. However with -c50 I was successful. A bit of trial and error is necessary.
• While hammering the site, delete the cache directory: rm -fr var/<siteaccess>/cache.
• Load the page, and if the bug was triggered some/all of the translations are now in English, and not in the language configured for the site access.

Some times I could trigger the bug on first delete of the cache, other times I had to delete the cache 3-5 times before the bug was triggered. This is a race condition which is generally hard to reproduce.