php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #43570 reason for some gettext errors found, need fix in interface
Submitted: 2007-12-11 20:43 UTC Modified: 2020-08-11 15:01 UTC
Votes:2
Avg. Score:4.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: foo at snarf dot de Assigned: cmb (profile)
Status: Closed Package: Gettext related
PHP Version: 5.2.5 OS: Debian etch 2.6.18-5-xen-amd64
Private report: No CVE-ID: None
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:
MUST BE VALID
Solve the problem:
46 - 25 = ?
Subscribe to this entry?

 
 [2007-12-11 20:43 UTC] foo at snarf dot de
Description:
------------
gettext works fine on one server, the precisely same source and .mo-Files fail to work on another (same OS, same PHP versions).

Reproduce code:
---------------
See some minimal gettext sample code on the web like the one below, it happens with all, really. 
<?php
setlocale(LC_MESSAGES,'az_AZ');
bindtextdomain("test","./locale");
textdomain("test");

echo _("text to translate");
?>

Expected result:
----------------
I would have expected gettext to work the same on both servers.

Actual result:
--------------
One server returned the expected result, the other just returned the message ID (gettext parameter).

I've found some similar reports on the web and here, but no solution yet; that's why I dug into it. 

Turns out, even if the correct .mo file is in the correct location, gettext fails if the respective *system* locale isn't installed. 
This is (somewhat) documented behaviour. But one doesn't get an exception, log entry or error message - just the default value. Which makes it REALLY hard to debug, especially when the server is a remote web host.

I suggest changing the gettext interface such as not finding the system locales for the selected language (if they are _really_ necessary) throws an Exception the fact. 
That way, people at least know what happened.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2011-03-23 00:34 UTC] clicky at erebot dot net
Sorry for digging up an old bug report. I'm merely posting this for others having the same problem you described.

To circumvent this, you may use this PEAR package: http://pear.php.net/package/File_Gettext
It provides a simple interface to load/edit/save gettext-compatible .po & .mo files.

There's also a "php-gettext" package in some Unix distributions which can also be used as an alternative to PHP's gettext extension.

Both of these are independent from the system's gettext library and therefore, don't have the bug you described.
 [2011-04-08 21:20 UTC] jani@php.net
-Package: Feature/Change Request +Package: Gettext related
 [2020-08-07 06:18 UTC] flo at dotbox dot org
I see the problem you have but I don't think changing the gettext behavior is the correct way to solve this.

I think this way because whats happening is just a symptom to a setlocale() call with an invalid locale (as in the locale does not exists on that machine).

IMHO this problem can be solved by checking the return value of the setlocale() call.
 [2020-08-11 15:01 UTC] cmb@php.net
-Status: Open +Status: Closed -Assigned To: +Assigned To: cmb
 [2020-08-11 15:01 UTC] cmb@php.net
> […] gettext fails if the respective *system* locale isn't
> installed.

In which case setlocale() is supposed to return FALSE.  If in
doubt, always check the return values of functions.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Oct 15 15:01:28 2024 UTC