On Wed, Jan 09, 2002 at 10:40:28AM +0100, Gaetano Paolone wrote: > Hi, > I am packaging a PHP4 application. > This software has been localized so there are > lines like:
> <? echo gettext ("Hello world");?>
> instead of:
> <? echo "Hello world";?>
> I was able to generate the po file with xgettext
> and the mo file with msgfmt.
> I have always been in troubles with locales, so
> here are my questions:
> 1) has the original gettext source code to be written in english?
> The software I am working on is not in english and so
> it will generate a po in another language (italian).
> I can manage to make the english po file (translating it) but I am sure
> that it would be much more easy to translate this software
> in russian starting from the english version rather than
> from the italian one. But you know, the upstream version
> is in italian so HAS it to be in english or not?
> Has the upstream author the need to change all the code in english
> or would it be a "good suggestion"?
Gettext can use any language as the source language; the source strings
are treated only as binary identifiers, so from gettext's point of view,
they can technically be anything at all. However, English text is
usually used because:
* World-wide, more people (including translators) will understand
English than any other single language. This makes it easier to find
people to do translations for your package into their own language.
* Source strings that are in ASCII can be represented legibly on
everyone's display. If your source string is in a language that needs
characters outside of ASCII, it may not be compatible with the character
set of the translator. This could make translation awkward even for
some translators who understand Italian.
* If the user has not set a locale, or the locale is set to C, gettext
will output the untranslated source string. Many people who speak
English fluently (even many non-native speakers) leave their system in
the C locale; they would be surprised to suddenly see Italian. :)
> 2) I know that it should be automatic, but would it be
> stupid to put a php code to ask for the user's language
> and then export the relative LC_ALL? (with the setenv
> php command)
PHP has a setlocale() function, that mirrors the behavior of the C
function of the same name (setlocale(3)). You should use this instead
of trying to export variables to the environment.
If this PHP app talks to a web browser, you can theoretically query the
accept-language http header. I never had much success with this,
because browsers usually send language settings as two-letter language
codes, and libc prefers a ll_CC locale setting.
> 3) I have in /etc/enviroment "LANG=it_IT", all my consoles
> are "localized" and everything seems to work quite well.
> The question is: Why PHP tells me that
> the LANG variable is "C" instead of "it_IT"? (I read the
> value with getenv php command). Where should php look for?
> Have I forgot something in declaring my "localization"?
Possibly a bug in PHP's locale handling; I remember there was a bug or
two with it the last time I looked. Or, it could be that
/etc/environment is not loaded by whatever script starts your webserver;
this seems likely. If you run the php script from the commandline using
php4-cgi, does it still say "C" instead of "it_IT"?
Cheers,
Steve Langasek
postmodern programmer
msg05190/pgp00000.pgp
Description: PGP signature
