Re: [hypermail] Language clearing task finished...

Yes I know. I've already saw such things in others mailing lists and it's very depressive to try to understand that a big hunch of letters means in fact 'Segmentation Fault' in deutch for example :)

But don't forget we can't go against the locale setting of the libc! I mean that if we use for example strerror() it will give us a locale string. And this is still the same... We could always get something like:

Hypermail: can't open mailbox: Fichier non trouve.

Well, this is always good to have a full package translated into all the possibles languages, as some peoples are really not good with english.

> I still consider the translation of the HTML output is what matters.
>
> If gettext is a good system for working with translated strings, then I think
> we should use it. If gettext isn't good at dealing with two different
> languages, then I think we should really think through which of the outputs
> that need gettext and which doesn't. If we can support only one language
> using gettext, is there then a point in supporting two different
> translations?

Ok allow me to explain a bit what gettext is able to do:

it can change the behavior of every functions that supports 'locale' output and on-the-fly string conversion. But this is done accordingly to the locale setting done by the user (or the admin). For example, here at home I have this into my .bashrc:

export LANG=fr
export LANGUAGE=fr

and then, into all 'GNU gettext'-enabled packages, they've put something like this:

  setlocale (LC_ALL, "");
  bindtextdomain (PACKAGE, LOCALEDIR);
  textdomain (PACKAGE);

with:

LC_ALL a #define from locale.h
PACKAGE & LOCALEDIR #defined from config.h (generated by configure)

Then, all the gettext functions will point to the 'right' language set as defined into the file LOCALEDIR/$LANG/PACKAGE.gmo

So if you have something like:

printf(_("Hello world\n"));

and something into your .gmo saying that, in french, "Hello world\n" should be translated into "Bonjour le monde\n", then the _() function will return the good char * pointer.

In the same manner, functions like

strcoll(), strxfrm() (for string comparaisons), strfmon() (for monetary formatting), isupper(), toupper() (you know them) or strftime() (for date and time formatting) will act as specified by the locale setting. For example in France, we write dates in the DD/MM/YYYY format and use 24h time format.

Hope I didn't gave you a headache... I sometimes have a bad habit: I speak too much :)

Ok here's my conclusions:

-) GNU gettext is only good for translating the stdout/stderr outputs of hypermail, since the LANG environment variable is defined 'out-of-the-box'.

-) The main goal of using gettext is clarify the lang.{c,h} system. Now we only have HTML-related strings into theses files, and all the rest is gone into the source code. Translating the stdout/stderr is not the main goal and surely will be another task (since the .po system is really different from the actual lang.h file). IMHO this could be a really nice solution not to have non-HTML and HTML strings mixed into the same translation package

-) One another thing: an admin *can* be allowed not to install the non-locale .gmo files. For example, I don't care about de, ru, sw, fi or others non-fr translations files. It's a disk-usage loss since I will never use them. But on a big mailing list system, this wouldn't be nice to have only 'english+locale' languages. As I said, I could for example host non-{english,french} mailing list. Then I think HTML-related strings have to be kept *into* the binary.

-) Finelly, as we only have HTML-related strings into our lang package, the function I've introduced (lang_tr()) can be enhanced to translate special chars to &-based strings.

Ok this is only my views over the subject :)

Regards,

• Nicolas Noble