From: Daniel Stenberg <daniel_at_haxx.se>
Date: Wed, 4 Sep 2002 10:16:48 +0200 (MET DST)

On Tue, 3 Sep 2002, Florian Mösch wrote:

> You are right. The GNU gettext library is not made for a SH-1 CPU.

Amen.

> But the message catalog files' format is not only platform independant and
> simple structured but also supprted by a *lot* of tool which help the
> translators.

It is also designed to be used by the gettext-system, why it fails to give us
what we want. For example, there are no IDs connected to the various
translated strings. Only strings. And we can't have run-time searching around
in strings.

Which was my main point when I said gettext isn't for us.

> I honor your offer to write all the tools needed for a proprietary format,
> but I think you should think about using a well tested and supported format
> for the catalog files.

Have you seen the format you're talking about? It is dead simple and it sould
be a subset of what we would prefer:

[extract from an actual .po file in my neighbourhood]

msgid "Write failed, closing control connection.\n"
msgstr "ÉCHEC d'écriture, fermeture de connexion de contrôle.\n"

> It is not necessary to implement the whole gettext library. But this
> approach already adresses some things that have not been mentioned here
> before.

I don't think it does.

> Only one example from gettext documentation:
>
> Assume we have the code
> printf("String `%s' has %d characters\n", string, number)
> A possible German translation for the above string might be:
> "%d Zeichen lang ist die Zeichenkette `%s'"

> A C programmer, even if he cannot speak German, will recognize that
> there is something wrong here.

Sorry, but I don't see how this addresses even one single shortcoming in my
suggested approach.

If you're talking about re-organizating the order of %s and %d etc, that is
simply not something that using gettext-format will help us support. In fact,
I think I can guarantee you that we won't support that, however fine it is
and however weird some translatoins will become because of this.

Simply because we don't want to implementa the sprintf() that kind of stuff
requires. I written a few such ones, I know what it takes.

> I don't think that we should even try to implement all those features at
> once.

Which features?

> But I still believe using a format which is already supported by helper
> applications for the translator would be a good idea.

I really fail to see how .po files is one bit easier to translate than the
format I've suggested.

-- 
Daniel "Bagder" Stenberg -- http://rockbox.haxx.se/

Received on 2002-09-04