|
php.net | support | documentation | report a bug | advanced search | search howto | statistics | random bug | login |
PatchesPull RequestsHistoryAllCommentsChangesGit/SVN commits
[2011-03-23 00:34 UTC] clicky at erebot dot net
[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
[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
|
|||||||||||||||||||||||||||||||||||||
Copyright © 2001-2025 The PHP GroupAll rights reserved. |
Last updated: Sat Nov 01 18:00:01 2025 UTC |
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.