Edit report at http://bugs.php.net/bug.php?id=53251&edit=1
ID: 53251
Comment by: greno at verizon dot 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:
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.
.
Previous Comments:
------------------------------------------------------------------------
[2010-11-24 09:48:53] paj...@php.net
I read your last comments and the behavior was not clear.
It is still not clear to me that PHP's binding should map one to one to
gettext behavior for this exact feature. It is exactly the opposite of
what other PHP APIs do and will create confusions to our users.
Also you misunderstood my point. In apache or other TS SAPIs the gettext
library has no way to know the script CWD. But they will get the server
CWD which is most likely either not readable (permission) or really not
what the users expect to be used.
As of getting this change in 5.3.4 or 5.2.15, it is too late. We are
already in RC phases.
------------------------------------------------------------------------
[2010-11-24 05:50:24] greno at verizon dot net
The current working directory (CWD) has nothing to do with the behavior
of bindtextdomain except in the sense of a point from which relative
paths will start. Any relative path must be stored as relative so that
if the CWD does change that the bind is then relative to the new working
directory.
The behavior must be exactly like I pointed out previously. Please read
through my previous posts carefully and try the examples shown from
python. Or for that matter run a test using straight GNU bindtextdomain
and you will see the proper behavior is as I have described.
And this needs to get into 5.2.15 and 5.3.4 as soon as possible.
.
------------------------------------------------------------------------
[2010-11-24 00:28:52] paj...@php.net
hi,
About the relative directories, what's about making them absolute before
passing them to gettext? The problem here is that the script CWD may not
be the library (apache or whatever else) CWD, that's the typical usage
of the virtual CWD.
Looking at the current implementation:
- has '0' any special meaning for bindtextdomain?
if not and if it is about testing empty string, this code is wrong and
ugly :)
- If an empty string is given, passing VCWD_GETCWD results should be the
right thing to do
- the current code has a leak, dir_name should be freed if VCWD_GETCWD
called succeeded
About including it in 5.3.4, it is too late. However trunk is open, so
please try to agree on the behavior(s) and update the patch accordingly.
------------------------------------------------------------------------
[2010-11-18 23:10:37] greno at verizon dot net
It's not whether there is a use case or not, that's how bindtextdomain
is defined to work.
The PHP implementation needs to work exactly like the GNU implementation
and other implementations in other languages such as python for example,
and right now it doesn't.
That's why I pointed out the fact that relative directories are valid
and in the case where a call is made with a NULL directory argument but
no previous setting was made, that the correct behavior is to return the
default locale directory for the system.
------------------------------------------------------------------------
[2010-11-18 22:31:20] jeanseb at au-fil-du dot net
I haven't svn access yet and I prefer that someone with more background
review this patch because it introduce an bc break.
For the relative path, I don't see any benefits to change this
behaviour. Can you produce a real use case. Thank's
------------------------------------------------------------------------
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
