"In the past, a long time ago, when PHP4 was not compatible and Savane was supporting PHP3, there was a special page include that were done only if PHP version was < 4.x, and this page was containing functions missing in PHP3.
This way, it is completely transparent and backward compatible."

Sure, we could do that. The current solution is transparent and backwards compatible. The function ngettext() will only be defined if PHP does not provide it; otherwise, the built-in function will be used.

"I must admit I do not remember the specifics. In fact, the configuration option was here mainly because this path differs from the other path (the prefix /usr/local valid for most all other links would break gettext in many cases)"

Right. If you want to allow both /usr/share/locale and /usr/local/share/locale (both are valid IMHO), it is no problem to modify savane to use either location. See below.

"It is only used at installation step (make install)."

... and that is exactly the problem. If the admin wants to install savane under /usr/local, the gettext calls will cease to work, because the .mo files are not in the expected location. However, we could check for /usr/local as well.

While the question about the NLSDIR is asked during configuration, it seems to me that after the installation the answer to that question is never used again. IMHO this is a bug. We should either drop that question completely (and thus install .mo files under /usr/share/locale, no matter what), or allow savane to search for .mo files using the specified location. Or we could limit the selection to either /usr/share/locale or /usr/local/share/locale. I think that those two paths are the only sane locations for .mo files.

"Anyway, your function should obtain this information the way gettext() does. Otherwise, we're just opening the door to complication (we would then need to pay attention where the files are, stuff would end up broken if someone moves the files to another legimitate location)."

No problem, I can change that function to use the default location.

"Upstream ngettext() is PHP 4.2.0. Too soon to use it everywhere - several distro stable version ships anterior versions. But it would be unwise to create something way complicated, that requires changes in the code, apart from the addition of a function, just for, say, one year."

Please don't get a wrong impression. It is just adding a custom ngettext() function, no other changes in the code are needed. Moreover, the syntax is completely identical to ngettext in PHP 4.2, so if that version is finally widely available, there's no need to change any code except to delete the custom ngettext function.

"This is not a bug. Savane is designed to work on unix-like system like GNU/Linux. There's no legitimate reason to have savane mo files in a directory which is not in the system path for the mo files; Savane cannot be installed on a user account anyway."

Sorry if I was unclear in my previous post, please s/user/admin/g in the text. I don't expect savane to work from somewhere under /home. However, I don't understand your point here:

"It would be pointless to add one more configuration option while were not forced to."

I don't need another option during the configuration; on the contrary. My understanding is that it would maybe even possible to remove that configuration question and just use the default .mo location (/usr/share/locale/).

"The question at the configure step is here for the sole purpose of catching the real system path for mo files. Not to encourage people to make a mess of their system files hierarchy."

I'm afraid I don't understand what you mean here. Why is it necessary to know the real system path when savane (at least the PHP part) does not honor it later on?

"I'm not sure to understand why you need this information. Where .mo files get installed is beyond what we need to control."

No, it's not, unfortunately. The ngettext() function I wrote needs to know where those .mo files are located, simply because it needs them to look up the translated string for a given plural msgid.

To put it explicitely: This function mimics the functionality of the original ngettext function. It is (at least to my knowledge) not possible to simply replace ngettext with some spiffy calls to the already implemented gettext() function. In other words, all the low-level binary reading of the .mo file is done in this ngettext() function I've written. So I need to determine the location of binary .mo files.

Moreover, I think there's another bug hidden in the i18n.php script. I haven't submitted it yet, but I'm pretty sure it exists:

During configuration, the user is asked where to install the binary .mo files. The default is /usr/share/locale/, but it's possible to specify any other directory. However, the setting of the textdomain in the i18n.php script is done without specifying the path to the .mo files, so in effect the PHP frontend of savane is always using the default location of /usr/share/locale/, regardless of what the user specified during configuration.

I suspect that every Savane installation just sticks to the default value, so nobody has noticed this bug yet.

Does the Perl backend use gettext as well? If not, the solution to the path-problem is rather trivial.

The ngettext() replacement I've written seems to work reliably enough that I am confident to make actually calls to it from the savane code.

However, before I proceed with this, there are two issues left. First, I need to find out where the savane.mo files are installed on the system. The usual location is /usr/share/locale/, but during Savane configuration, it is possible to specify a different location. Mathieu, is there a clean way to get the location of the binary .mo files?

The second issue is connected with bug #1981, and will show up when using Russian, Japanese, or Korean as the frontend language (= all non-ISO-8859-15 languages). Once bug #1981 is solved, the different encodings of the .mo files won't be a problem any more.

The custom ngettext() function is now checked in in the cvs HEAD. I've done some testing with it, and it works (see the GNA! test install).

The only area where I've applied a call to ngettext is in frontend/php/include/news/general.php, which uses it to display the number of replies to a news item. You can see the effect on the news pages, obviously.

Currently, it only works for English and German, simply because other languages have no translated plural forms yet.

My next step will be to ask translators to update this single string ("%s reply") in their .po file, so I can do some more testing. As this msgid is not used anywhere else, it should not interrupt the operation of the main savane install on GNA!.

Hi,

I've written a custom ngettext() function which works for me. Now I'd like to do some testing with the savane code, to adjust the function accordingly.

May I commit this change to the HEAD of cvs, or should I create a branch for this task?

Strange decision by PHP team... What version of PHP does Gna! run on?

Anyway, you could start now. Simply do something like

function savane_ngettext ($string1, $string2, $number)
{
if (function_exists ("ngettext"))
return ngettext ($string1, $string2, $number);

// This is a drawback, though, ``items'' instead of ``item(s)''...
// Maybe another argument, `$fallback'?
return $string2;
}

We see more problems with UTF-8 in the original submission, BTW...

In some places in Savane (at least the trackers), one can see strings like ``19 item(s)''. Savane should use ngettext() for these strings to make the proper form.

This would make two improvements:

• Savane would look more intelligent in English: ``1 item'', but ``19 items''.

• More importantly, some languages, such as Russians, have more than two forms for plural nouns. ngettext() allows to correctly handle them all and avoid incorrect grammar or constructs like ``19 &#1101;&#1083;&#1077;&#1084;&#1077;&#1085;&#1090;(&#1072;,&#1086;&#1074;)'' with multiple endings in parentheses.