ID: 49349
Updated by: paj...@php.net
Reported By: raulsalitrero at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: Gettext related
Operating System: win32 only - windows xp sp3
PHP Version: 5.3.0
-Assigned To:
+Assigned To: pajoye
New Comment:
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.
Previous Comments:
------------------------------------------------------------------------
[2009-09-24 16:51:48] 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?
Regards,
Belman Kraul
------------------------------------------------------------------------
[2009-09-09 12:55:57] 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
<?
putenv("LC_ALL=ru");
echo setlocale(LC_ALL,"ru");
bindtextdomain("messages", "./locale");
bind_textdomain_codeset("messages", "utf8");
textdomain("messages");
echo _("Application");exit;
?>
In php 5.3.0 it does not translate.
------------------------------------------------------------------------
[2009-08-24 16:49:49] raulsalitrero at gmail dot com
Description:
------------
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:
locale/
enu/...
en_us/...
en_US/...
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\domain.mo" (locale folder
name) or the full path something like
"C:\Apache\htdocs\app\locale\en_US\LC_MESSAGES\domain.mo" or
"/var/www/app1/locale/en_US/LC_MESSAGES/domain.mo" in *nix (even if the
file doesn't exists to know if its necessary to rename/move folders
thanks in advance
Reproduce code:
---------------
<?php
$locale = "en";
@error_reporting(E_ALL - E_NOTICE);
$mensaje="";
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";}
textdomain("messages");
bindtextdomain("messages", "locale");
bind_textdomain_codeset("messages","UTF-8");
textdomain("messages");
echo _("hola mundo");
Expected result:
----------------
(having messages.po and messages.mo 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)
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=49349&edit=1
