|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #49349 gettext behaves differently in php 5.3.0 (5.2.x ignored setlocale errors)
Submitted: 2009-08-24 16:49 UTC Modified: 2016-09-08 09:37 UTC
Avg. Score:4.7 ± 0.6
Reproduced:59 of 59 (100.0%)
Same Version:52 (88.1%)
Same OS:38 (64.4%)
From: raulsalitrero at gmail dot com Assigned: pajoye (profile)
Status: Closed Package: Gettext related
PHP Version: 5.3.0 OS: win32 only - windows xp sp3
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
Solve the problem:
35 - 30 = ?
Subscribe to this entry?

 [2009-08-24 16:49 UTC] raulsalitrero at gmail dot com
usign gettext functions under php 5.3.0 (built with vc9) works differently to how it used to work in php 5.2.x (tested on 5.2.10 built with vc6).

it used to work even after a setlocale error, (locale not supported on my machine), after the error it continued loading the .mo (.po) files from the locale folder in the app. in php 5.3 it doesn't seem to load the files, i've tried changing the locale to the correct name for windows wich is "enu" and the path to the correct locale folder to:
  English_United States/...
  English_United States.1252/... (changing the setlocale codeset from "UTF-8" to "CP1252" and "1252", and various combinations of the above settings, also with and without the codeset functions, and it didn't show translations.

in php 5.2.10 it loaded the files directly from the first settings
id like to know if it is possible to make php_gettext to ignore the setlocal error and work out the folder name from the LANG and LC_ALL enviroment variables like it apparently used to be in earlier versions of php. or if it would be too much troublesome, then if it could be possible to add a new function that returns the folder name where the the .mo files are being expected to be, something like:

gettext_getpath([$text_domain = Current_default_domain])

and get something like "en_US\LC_MESSAGES\" (locale folder name) or the full path something like "C:\Apache\htdocs\app\locale\en_US\LC_MESSAGES\" or "/var/www/app1/locale/en_US/LC_MESSAGES/" in *nix (even if the file doesn't exists to know if its necessary to rename/move folders

thanks in advance

Reproduce code:
	$locale = "en";
	@error_reporting(E_ALL - E_NOTICE);
	if (isSet($_GET["locale"])){
		$locale = $_GET["locale"]; 
	setlocale(LC_ALL, $locale);
	if(false == putenv("LC_ALL=$locale")){echo "error lc_all";}
	if(false == putenv("LANG=$locale")){echo "error lang";}
	if(false == putenv("LANGUAGE=$locale")){echo "error language";}
	bindtextdomain("messages", "locale");
	echo _("hola mundo");

Expected result:
(having messages.po and files with the translation "hola mundo" -> "hello world" (english)
in the relative path "locale/en/LC_MESSAGES/"

"hello world"

Actual result:
"hola mundo" (text not being translated)


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2009-09-09 12:55 UTC] ameoba32 at gmail dot com
On windows vista sp2 + php-5.3.0-Win32-VC9-x86 

gettext function always searches for "en_US" or "en" path in locale directory.

PHP 5.2.3 is okay.

this code produces different results

echo setlocale(LC_ALL,"ru");
bindtextdomain("messages", "./locale");
bind_textdomain_codeset("messages", "utf8");
echo _("Application");exit;

In php 5.3.0 it does not translate.
 [2009-09-24 16:51 UTC] bkraul at yahoo dot com
I was wondering this this issue is expected to be resolved in the near future? Right know I have gotten around it by reverting back to php 5.2.11. Is this a problem with the extension itself?


Belman Kraul
 [2009-09-24 18:05 UTC]
Yes, but nobody managed to get to it at this stage. I assign it to me so I won't forget to check this problem.

To ease my work it would be nice if someone can zip a working script with 5.2, with mo/po files, where it should be placed, etc. and describe. That will shorten the time I will have to spend on the issue.
 [2009-10-02 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2009-10-14 13:45 UTC] roger dot olivier at gmail dot com
As asked by you can found here an archive with a working script with 5.2.5 and not with 5.3.0
Tested on Xp pro Sp3

Unzip and launch index.php.
Expected result => print "Hello world" on screen
Actual result =>   print "bonjour le monde" on screen
 [2009-12-08 13:57 UTC] paulw at torchtrust dot org
I am also getting this big. Is it fixed in 5.3.1? Is there a work 
 [2009-12-18 15:44 UTC] bengibollen at hotmail dot com
I have got this problem as well. I'd like to add that the system default language/locale gets translated. But no other languages.
I have windows vista, English version, and the system default locale is set to Swedish. The strings that are supposed to be translated are all written in English; _("Hello World!").

I have made three translations:
./en/LC_MESSAGES/ /*nonsense words/phrases only for testing*/

I always get the Swedish translation no matter what configurations* I try. If I rename the Swedish translation file I get no translation at all, only the default string.

* I've tried all kind of parameters for the following:
setlocale(LC_ALL, ...);
 [2010-04-05 17:19 UTC] euridica at narod dot ru
Still same in 5.3.2. Translation is done only to default system locale.
 [2010-04-14 01:17 UTC] jorgecanta47 at hotmail dot com
Same problem here with Windows Vista Home Premium, PHP 5.3.1 in XAMPP.
Is there any workaround  yet?
 [2010-04-19 02:00 UTC] egorinsk at gmail dot com
Hi, the same problem here with Windows XP SP2 and PHP 5.3.1 .  In PHP 5.2, setlocale() call failed, but gettext() used information from LANG, LC_ALL and LANGUAGE variables. That was good, because I could use putenv() to change gettext() language on Windows and setlocale() on Linux.

But now setlocale() on Windows fails, and gettext() always uses system locale, and messages are not translated. Actually, I don't need locales, they only bring problems, I'd prefer to always set it to POSIX locale to get consistent behaviour independent from server setup, but gettext() requires to use it :(
 [2010-05-05 12:12 UTC] sjake_it at hotmail dot com
Same problem here with Windows Server 2003 SP2.
This bug prevents me from upgrading to php 5.3.x
It's been 8 months now so I hope this bug will be fixed quickly now.
 [2010-05-06 06:00 UTC] scott at etw dot ca
Is there a release date for 5.3.3?  Spent the last few months building a project in 5.3 and my final steps was to add language support which i cant do with gettext due to this bug, and to revert to 5.2x would require other major code changes....
 [2010-05-06 09:20 UTC]
The work around is explained in this report. And yes, there will be a 5.3.3 which will have the fix in the library used by gettext.
 [2010-05-12 06:46 UTC] xxxxviii at iinet dot net dot au
Windows Server 2008 R2 x64 with IIS 7.5
PHP 5.3.0, 5.3.2

Locale is English (Australian). Trying to get English (United States) to work.

have ./locale/en_AU/LC_MESSAGES/

Always get the default (Australian)

You stated: "The work around is explained in this report."

So, but this escapes me. Where  is the workaround? I have read this thread several times.

Question: why does _SERVER["HTTP_ACCEPT_LANGUAGE"] have en-AU and not en_AU??? Or is this just a silly Winblows thing.
 [2010-05-12 19:14 UTC] jasonsmith at yahoo dot com
Is there a release date for 5.3.3?
 [2010-05-12 19:41 UTC]
No release date yet.

Please, don't add other cases as the issue has been identified, clearly.
 [2010-06-29 23:00 UTC] raulsalitrero at gmail dot com
just as a note.
i have just compiled the last version of libintl 0.18.1
taking the patch used for the previous version as a base
but the problem persists.

also you stated: "The work around is explained in this report."

but i don't know what exactly that means. 
what workaround.?

Do you mean the pure php gettex implemementation, i know it works, but it can be
really slow.

thanks in advance.. 
 [2010-07-14 15:14 UTC]
By the way, reading again the gettext source code (the intl library), the name of the language environment is LANGUAGE, not LANG. At least in the recent versions.

Next 5.3.3RC-vc9 will have the fix (due tomorrow).
 [2010-08-08 16:16 UTC]
-Status: Assigned +Status: Feedback
 [2010-08-08 16:16 UTC]
Please try with 5.3.3 final.
 [2010-08-09 18:03 UTC] raulsalitrero at gmail dot com
yes!!, it works now, thanks a lot man!!, so the error was in gettext sources...

what was the problem actually?...
 [2010-11-06 01:57 UTC]
-Status: Feedback +Status: Closed
 [2011-04-14 13:33 UTC] czarny at gmx dot net
I have this bug again under PHP 5.3.5
Build Date 	Mar 9 2011 15:46:03
Compiler 	MSVC9 (Visual C++ 2008) 

Under Win7 I find no way to set nor the LANG nor the LANGUAGE env-var nor the locale via setlocale() so that the correct po-file can be found by gettext. I get always the translations from the default locale folder as mentioned above.
 [2016-09-08 09:31 UTC] mirazmac at gmail dot com
I don't this is funny or not. But believe me, I'm running PHP 7.0.10 and this problem is NOT fixed yet! :(
And drop-in libraries like "php-gettext" doesn't works with Poedit & other software.
 [2016-09-08 09:37 UTC]
@mirazmac: since the original reporter said this bug was fixed, and since it's also a few years old, please make a new bug report with your own description and reproducing code.
 [2017-12-17 18:55 UTC] alex at khimich dot org
As of 2017 and PHP 7.1.5 it is not working... Very sad.
 [2018-01-27 17:18 UTC] info at dezoos dot es
Same here, php 5.6 under iis runing in Windows Server 2012 R2 Standard Edition. We are using an es_ES and en_EN locale and don't work, But was working with php 5.2 in the same system.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Jul 19 18:01:30 2024 UTC