Edit report at http://bugs.php.net/bug.php?id=53251&edit=1
ID: 53251
Updated by: paj...@php.net
Reported by: jeanseb at au-fil-du dot net
Summary: bindtextdomain with null directory doesn't return
the previously set
Status: Open
Type: Bug
Package: Gettext related
Operating System: Debian 5.0.6
PHP Version: 5.3.3
Block user comment: N
Private report: N
New Comment:
Using your script: it happens exactly what I explained earlier. The
library does not find the locale because its CWD is not the same as the
script CWD (which is a virtual CWD, created by the engine and specific
to the engine).
I suppose you use Apache in a non thread safe mode, that won't show you
the effect I was referring to as it happens only with threaded SAPI.
Previous Comments:
------------------------------------------------------------------------
[2010-11-24 20:44:02] greno at verizon dot net
The patch upload apparently won't take a zip.
The PHP bindtextdomain brokenness demonstration app can be found here:
http://greno-misc.googlecode.com/files/testbindtextdomain.zip
.
------------------------------------------------------------------------
[2010-11-24 20:32:59] greno at verizon dot net
Yes, I read and perfectly understood your comment.
There is no problem with CWD when using gettext. I've tested this many
times.
I prepared a little app that demonstrates the bindtextdomain problem.
There is a README.txt that explains in the zip.
I didn't see any way to attach a file to the bug so I'm taking the
liberty of attaching it as a Patch but it is not really a patch. It
demonstrates the problem of multiple translation stores with the broken
bindtextdomain.
------------------------------------------------------------------------
[2010-11-24 17:47:26] paj...@php.net
For my own sake, please take 2.5 min to understand my comment.
Questions:
- relative directories, relative to what? CWD? Then please double read
my comment, check how PHP works (or any other languages working as
module of a server)
At any point after the call, the CWD can be different. The CWD inside
the gettext library (read: inside the gettext library) is not (read: is
not) equal to the actual script CWD, which is a virtual CWD based on the
directory where the script, unless the script changes using the chdir()
PHP function.
I perfectly understand what you said about how it should work, but that
does not help to resolve the actual problem. How in the world do you
know which CWD will be used by the library?
------------------------------------------------------------------------
[2010-11-24 17:43:41] greno at verizon dot net
In addition, consider the case where you need to temporarily remap the
domain directory to another translation store.
// WORKING WITH MULTIPLE TRANSLATION STORES:
bindtextdomain("messages", "./locale");
textdomain("messages");
...
// work with local translation store
...
// now need to get some translations from a different translation store
savedmapping = bindtextdomain("messages", NULL);
bindtextdomain("messages", "/pathtodifferentstore/locale");
...
// temporarily work with different translation store
...
// now we need to restore previous mapping
bindtextdomain("messages", savedmapping);
...
// once again working with previous translation store
...
Right now with PHP you cannot work with any nested heirarchy of multiple
translation stores because you have no idea what is the current domain
directory mapping so you cannot save it and restore it later.
.
------------------------------------------------------------------------
[2010-11-24 17:23:31] greno at verizon dot net
Fixing the broken bindtextdomain behavior is not going to create any
confusion for any user.
In fact, right now I can simulate the correct behavior by having an app
store/restore the domain directory mapping from a separate tracking
mechanism and all of gettext including bindtextdomain in PHP then works
perfectly as it should.
The issue is that most users would be expecting bindtextdomain to work
correctly so that they could retrieve the current directory mapping
using a NULL argument without having to resort to creating their own
separate tracking mechanisms for keeping track of that state.
When I create a small PHP file holding something like:
bindtextdomain("messages", "./locale");
textdomain("messages");
And then I import that file into my files such as:
/index.php
/subapp1/index.php
/subapp2/index.php
It means that each of the directories ( /, /subapp1, /subapp2 ) are
expected to have their own 'locale' directories. This way all
translations related to /subapp1 are stored in /subapp1/locale/...,
those for /subapp2 are stored in /subapp2/locale/...
Because the binding is relative you do not need to be resetting and
manipulating the domain directory binding all the time to achieve
translations using a local locale directory.
There should be no difference between the PHP implementation of
bindtextdomain and the GNU implementation(C) which is also the same as
is found in Java, Python, and other languages. If you have any doubt go
test these languages.
// HERE IS THE BEHAVIOR THAT SHOULD OCCUR:
// no mapping in effect yet
bindtextdomain("messages", NULL); // should return default system locale
directory, eg: "/usr/share/locale" on Linux
// now we create a relative mapping
bindtextdomain("messages", "./locale"); // set a relative domain
directory mapping
bindtextdomain("messages", NULL); // should return "./locale"
// now we create an absolute mapping
bindtextdomain("messages", "/absolutepath/locale"); // set an absolute
domain directory mapping
bindtextdomain("messages", NULL); // should return
"/absolutepath/locale"
And this is exactly the behavior of the other languages and of the GNU
(C) implementation. And PHP needs needs to fix its broken behavior.
As far as getting this fix in the RC's for 5.2.15 and 5.3.4. This
change fixes something that is badly broken and it warrants an
exception.
.
------------------------------------------------------------------------
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
http://bugs.php.net/bug.php?id=53251
--
Edit this bug report at http://bugs.php.net/bug.php?id=53251&edit=1
