Req #43570 [Opn->Csd]: reason for some gettext errors found, need fix in interface

From: Date: Tue, 11 Aug 2020 15:01:59 +0000
Subject: Req #43570 [Opn->Csd]: reason for some gettext errors found, need fix in interface
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-228515@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=43570&edit=1 ID: 43570 Updated by: cmb@php.net Reported by: foo at snarf dot de Summary: reason for some gettext errors found, need fix in interface -Status: Open +Status: Closed Type: Feature/Change Request Package: Gettext related Operating System: Debian etch 2.6.18-5-xen-amd64 PHP Version: 5.2.5 -Assigned To: +Assigned To: cmb Block user comment: N Private report: N New Comment: > […] 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. Previous Comments: ------------------------------------------------------------------------ [2020-08-07 06:18:19] 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. ------------------------------------------------------------------------ [2011-03-23 00:34:16] 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. ------------------------------------------------------------------------ [2007-12-11 20:43:41] 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. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=43570&edit=1

« previous php.bugs (#228515) next »