Workaround for gettext caching issue in PHP
gettext is the GNU internationalization and localization (i18n) library, which can be used in almost any programming language. And, of course, it can be used under PHP too, to internationalize your web applications.
I will not go into gettext usage details, there are enough resources available for that.
Official PHP gettext documentation:
http://www.php.net/manual/en/book.gettext.php
A nice “gettext introduction” and well-done article:
http://mel.melaxis.com/devblog/2005/08/06/localizing-php-web-sites-using-gettext/
Some benchmarks:
http://mel.melaxis.com/devblog/2006/04/10/benchmarking-php-localization-is-gettext-fast-enough/
And now let’s get back to what I actually wanted to talk about. It’s a well known problem that new or updated translated strings don’t appear immediately on your PHP page. Or to say the truth – they don’t come up at all. This happens only if you are running PHP as a module (mod_php, …) inside your webserver (Apache, etc), it does not affect php scripts run as CGI.
Why does it happen? The short answer is – because of caching.
The first time you are initializing a text domain (loading a compiled binary .MO file), the file is loaded and cached in memory. Performance-wise, this is a very good thing, the translation string lookups run very fast and not needing to check the filesystem again and again helps a lot with the speed.
The disadvantage is that if you update the .MO file or even delete it, gettext will not catch the change, it would still run with the file from the cache. Very irritating, especially in a development environment.
The recommended and most well-known solution is to restart the web server – this will restart the PHP module with its gettext extension and the cache will be cleared. Unfortunately restarting the web server is not always something that can be done easily, or we might not even have the privileges to do it if we’re on a shared hosting.
I came up with a workaround, that does not require fiddling at all with the web server, it’s all done through PHP. Basically, what we do, is make sure that we are always using the last updated .MO file by using copies of it. We check for modifications by checking the file modification time using filemtime and then we make sure that’s the one we’re using by binding to a unique text domain and a filename computed from the file modification time. If that file exists (from a previous run), then that’s all. But if it doesn’t exists, then create it by copying the original .MO file. So, what we are actually doing is activating a new unique translation domain for each and every time the .MO file is modified.
What you need to consider:
- you need write permissions in the locale folder
- if you update the .MO file many time, then a lot of garbage temporary .MO files are generated – you need to remember to clear the folder once a month or something like that
- is meant to be used in a development environment only, the filesystem checks are not benchmarked (even though PHP filestat caching may help here) and may be too expensive on a production server.
Finally, the example code is:
// settings you may want to change $locale = "en_US"; // the locale you want $locales_root = "locales"; // locales directory $domain = "default"; // the domain you're using, this is the .PO/.MO file name without the extension // activate the locale setting setlocale(LC_ALL, $locale); setlocale(LC_TIME, $locale); putenv("LANG=$locale"); // path to the .MO file that we should monitor $filename = "$locales_root/$locale/LC_MESSAGES/$domain.mo"; $mtime = filemtime($filename); // check its modification time // our new unique .MO file $filename_new = "$locales_root/$locale/LC_MESSAGES/{$domain}_{$mtime}.mo"; if (!file_exists($filename_new)) { // check if we have created it before // if not, create it now, by copying the original copy($filename,$filename_new); } // compute the new domain name $domain_new = "{$domain}_{$mtime}"; // bind it bindtextdomain($domain_new,$locales_root); // then activate it textdomain($domain_new); // all done
