gettext Specific strings don't get translated

Question

I have a working gettext installation in a PHP-powered web site (PHP/5.3 running as Apache module on Windows). The problem is that certain arbitrary strings do not get translated. A few texts (less than 1% and always the same) remain in the original language. The crazy bit is the details:

• Surrounding strings do get translated:

  Line 95: <th><?php echo _('Address'); ?></th> <-- Translated -->
  Line 96: <th><?php echo _('Number'); ?></th>  <-- Not translated!!! -->
  Line 97: <th><?php echo _('City'); ?></th>    <-- Translated -->
  

• It's 100% reproducible in another PHP/5.3 server with different Windows version and architecture: I have problems in the very same strings.
• If I change source text, translation or both, problems persists in exactly the same location.
• Affected strings are fairly uninteresting (no non-ASCII characters at all or any particularity I can think of).

Any idea or hypothesis?

Answer 1

The gettext library depends on locale information transmitted in environment variables. That's extremely unreliable on the Apache mod_php SAPI (aka "PHP as Apache module") on Windows because a single thread will typically be shared by different scripts.

In my case, I was running http://parent.example.com which made an internal HTTP post request (with Curl) to http://child.example.com and then composed and printed the results. It happens that both sites are hosted on the same site so both scripts shared environment and I was getting this sequence:

1. Parent sets "parent.mo" as catalogue
2. Child sets "child.mo" as catalogue
3. Parent wants to print translated texts, gets stuff from wrong catalogue
4. Both sites are related thus they share many strings, but not all (thus the red herring of getting most translations.

I was able to diagnose this using the Process Monitor utility. I captured data while doing a page load and then filtered by "path ends with .mo". That revealed that Apache was loading an unexpected catalogue in addition to the right one.

As quick & dirty workaround I'm calling bindtextdomain() and textdomain() again right after curl_exec(). (In the long term I'll have to migrate to FastCGI, use a pure PHP gettext library or convince the client to switch to Linux, whatever's easier.)