Edit report at https://bugs.php.net/bug.php?id=66265&edit=1
ID: 66265
Comment by: swbva at thecloudindex dot com
Reported by: roeycohen at gmail dot com
Summary: gettext is not working anymore
Status: Assigned
Type: Bug
Package: Gettext related
Operating System: windows
PHP Version: 5.5.7
Assigned To: ab
Block user comment: N
Private report: N
New Comment:
Same kind of problems here...
PHP 5.4 works fine, PHP 5.5 doesn't
I'm on Win7-64.
Correct locale identifiers (region & language) for Windows can be found in this table (last 2
columns):
http://www.microsoft.com/resources/msdn/goglobal/default.mspx
(But, as some may know of course, other ways to indicate the locale on Windows are possible, see
e.g.: http://msdn.microsoft.com/en-us/library/39cwe7zf%28v=vs.100%29.aspx)
There DO seem to be some inconsistencies in PHP 5.5.
For example; setting a locale named 'en' seems to be valid. PHP 5.4 returns (correctly?)
false
A little comparison ('locale': setlocale() return string):
5.4
en: false
en_US: false
en-US: false
enu: English_United States.1252
5.5
en: en
en_US: false
en-US: en-US
enu: English_United States.1252
Windows seem to add the codepage the the locale string. Since my language files are in utf-8 (not
cp1252), I hope this doesn't cause troubles?
It doesn't seem possible to add the encoding the the locale string in Windows.
(Btw; of course, it IS working in PHP 5.4 already..)
Another thing: what seems to work in PHP 5.4, is e.g. using putenv("LC_ALL=en"), with my
english LC_MESSAGES in a folder named 'en'.
Of course this isn't a valid (Windows) locale, but it IS what I want regarding Gettext in my
case (1 file for the english language, disregarding region).
Is this a valid practice? I believe the LC_ALL variable is temporary set/altered, and immediately
restored to it's original/previous value after PHP is finished with Gettext? (So if it is
working, it doesn't do any possible harm?)
Btw; only LC_ALL env. variable seems to matter for gettext?
I seems I can use anything for setlocale, and Gettext still will get the right file? (on Win/PHP 5.4
anyway..)
Ps; I am wondering what exactly worked for roeycohen (and how?)
I can reproduce his problem, but can't solve it?
Previous Comments:
------------------------------------------------------------------------
[2014-01-21 15:32:54] alvaro at demogracia dot com
Not sure if it's the same issue (I'll be glad to open a separate ticket otherwise) but in
my case gettext is always loading the same catalogue. There's no say to change the language
from within PHP. It happens with every PHP/5.5 version (VC11 TS x86) I've tried: 5.5.5, 5.5.6,
5.5.8... However, it works as expected with PHP/5.4 (VC9 TS x86).
I have this test code [1] I run from the command-line in a Windows 7 (x64) with Spanish locale:
<?php
if(!defined('LC_MESSAGES')){
define('LC_MESSAGES', 5);
}
bindtextdomain('gettext', __DIR__ . '/locale');
bind_textdomain_codeset('gettext', 'UTF-8');
textdomain('gettext');
$languages = array(
'es',
'es_ES',
'en',
'en_GB',
'english',
'english-uk',
'uk',
'britain',
'england',
'eng',
'totally_invalid',
);
foreach($languages as $locale){
putenv("LC_ALL=$locale");
echo $locale . ': ' . _('__translate_this__') . PHP_EOL;
}
In PHP/5.4 I get this:
es: Loaded from Spanish catalogue
es_ES: Loaded from Spanish catalogue
en: Loaded from English catalogue
en_GB: Loaded from English catalogue
english: __translate_this__
english-uk: __translate_this__
uk: __translate_this__
britain: __translate_this__
england: __translate_this__
eng: __translate_this__
totally_invalid: __translate_this__
In PHP/5.5 I get this:
es: Loaded from Spanish catalogue
es_ES: Loaded from Spanish catalogue
en: Loaded from Spanish catalogue
en_GB: Loaded from Spanish catalogue
english: Loaded from Spanish catalogue
english-uk: Loaded from Spanish catalogue
uk: Loaded from Spanish catalogue
britain: Loaded from Spanish catalogue
england: Loaded from Spanish catalogue
eng: Loaded from Spanish catalogue
totally_invalid: Loaded from Spanish catalogue
Just to be sure, I've tested it with stripped down PHP installations:
php-5.5.8-oficial-VC11
â php.exe
â php.ini
â php5ts.dll
â
ââââext
php_gettext.dll
... where php.ini only contains this:
[PHP]
extension_dir = "ext"
extension=php_gettext.dll
... and I manually clean up PATH before running my tests:
PATH=C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem
Setting a LANG variable manually from command prompt *does* change the catalogue (I get "Loaded
from English catalogue" every time):
set LANG=en_US
... but setting it from PHP itself (though apparently successfull) doesn't affect the loaded
catalogue at all:
var_dump( putenv('LANG=en_US'), getenv('LANG') );
bool(true)
string(5) "en_US"
I've tried every variation of putenv() or setlocale() I've been able to think about.
[1] Test code: http://alvaro.es/archivos/gettext-bug-66265.zip
------------------------------------------------------------------------
[2013-12-17 08:53:17] roeycohen at gmail dot com
it worked!:)
------------------------------------------------------------------------
[2013-12-16 18:05:16] ab@php.net
Hi,
after further debugging it turned out, that the issue might be laying somewhere else. With CLI,
could you please try the following
- set LANG=en_US
- run php snippet.php
After that your first snippet works as well. Could you confirm that?
To install additional locales, on win8 i go to
Control Panel\All Control Panel Items\Language
Maybe that's edition dependent, but one could try.
Thanks
------------------------------------------------------------------------
[2013-12-12 11:57:40] roeycohen at gmail dot com
My current locale is indeed he_IL: hebrew(israel).
i'm not sure how to install another locale... but my machine is able to display english
characters :))
when i switch between php versions, i do it on the same machine: i stop iis, rename the php folders
and start the server again.
I also ran the script using CLI and got the same results.
------------------------------------------------------------------------
[2013-12-12 11:31:22] ab@php.net
ups, set back the php version
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=66265
--
Edit this bug report at https://bugs.php.net/bug.php?id=66265&edit=1