|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #21965 gettext uses entries out of different files at the same time
Submitted: 2003-01-30 10:47 UTC Modified: 2004-04-04 09:45 UTC
Avg. Score:4.0 ± 1.0
Reproduced:9 of 9 (100.0%)
Same Version:3 (33.3%)
Same OS:1 (11.1%)
From: thorsten dot kussler at communardo dot de Assigned:
Status: No Feedback Package: Gettext related
PHP Version: 4.2.3 OS: Solaris
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: thorsten dot kussler at communardo dot de
New email:
PHP Version: OS:


 [2003-01-30 10:47 UTC] thorsten dot kussler at communardo dot de
gettext uses entries out of differend files at the same time!!

During the execution time of on single script the languages changes without an reproduceable behavior.

As an example:
the first 10 strings are translated in german, the next three strings in english, the next vive  again in german and thze rest in english.

The same application on a different OS like LINUX or Windows works pretty well. It is only a problem on Solaris. 

The version of GNU gettext is 0.10.37 on all systems.

Please could you help me finding a solution.

Thorsten Kussler


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2003-01-30 11:00 UTC] thorsten dot kussler at communardo dot de
This behavior is reproduceable on Solaris 7.x and 2.6
 [2003-01-30 11:43 UTC]
Are you using gettext in multi-threaded enviroment if so, that would explain the behaviour you are seeing because gettext is NOT thread-safe.
 [2003-01-30 12:20 UTC] thorsten dot kussler at communardo dot de
I thought that it might be a problem. PHP is compiled --width-apache and not as an CGI. 
I set explicitly the LC_MESAGES var infront of each call of gettext because of that. 
The behavior is the same if i'm the only user on the server.
How is that behavior explicable with thread conflicts ???

I have no idea

have you any other experiences with that phenomena or examples of problematic system configurations?
 [2003-07-12 23:37 UTC]
I bet this happens with later PHP versions, like 4.3.2 too?
What is the full configure line you have used to configure PHP ??

 [2003-07-15 02:19 UTC] thorsten dot kussler at communardo dot de
The configure line was:
'./configure' '--with-oci8=/home/oracle/product/8.1.7' '--with-apxs=/usr/local/apache/bin/apxs' '--with-gettext=/usr/local' '--with-ldap=/usr'

and a second version directly compiled with Apache (--with-Apache)
 [2003-07-15 02:21 UTC]
Please try using this CVS snapshot:
For Windows:

And if it still happens, provide a short test script.

 [2004-03-28 08:27 UTC] timo dot hummel at 4fb dot de
I can confirm this. This bug especially occurs when the following conditions are met:

- Multiple domains
- Switching forth and back between different languages

I reproduced this on a RedHat 9 system, with the following results:

After a certain period of time, the strings for any second textdomain are switching between the translated and untranslated string; seems like it's because the different HTTP server processes. After restarting the web server, the problems can't be reproduced, or when the path is being changed.

Does the PHP gettext implementation cache the results after getting the gettext string from the gettext library?

That would explain the troubles.
 [2004-03-28 11:33 UTC]
Are you always calling textdomain() at the beginning of your script?  There is no code in the gettext extension, as far as I can see, that resets the default text domain after a request, so the text domain from one request is going to leak to the next for any particular httpd process.  The workaround is obviously to always explicitly set it at the beginning of every request.
PHP Copyright © 2001-2023 The PHP Group
All rights reserved.
Last updated: Thu Sep 28 22:01:24 2023 UTC