Follow-up Comment #10, bugs #1986 (project savane):
"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.
_______________________________________________________
Reply to this item at:
<http://gna.org/bugs/?func=detailitem&item_id=1986>
_______________________________________________
Message sent via/by Gna!
http://gna.org/
_______________________________________________
Savane-dev mailing list
[email protected]
https://mail.gna.org/listinfo/savane-dev
