[sane-devel] SANE i18n: only one translation file per language?

[Henning Meier-Geinitz]

Hi,

On Sun, Dec 01, 2002 at 12:19:22PM +0100, Oliver Rauch wrote:
> There is one problem with this.
> In the moment the backendss have implemented some options in different
> ways.

Yes, but then the English titles and descriptions should be different.
And in this case, the translations would be different, too. --> no
problem.

If the definitions are the same, e.g. one backend uses (from your
example):

> when the backend uses an option of saneopts.h:
>   scanner->opt[OPT_NEGATIVE].title  = SANE_TITLE_NEGATIVE;

and another one:

    scanner->opt[OPT_NEGATIVE].title  = SANE_I18N("Negative");

Then the titles are the same and should be translated the same. No
problem either. The only possible problem is, that in the old system,
someone could have translated the saneopts "Negative" to (German)
"Negativ" while a backend author uses "Negativ-Modus". We just must
decide which one is better. But I don't think there are too many of
these clashes.

> I think it is impossible to create a common translation for
> all backends.

I don't think there is a technical problem, just a "social" one.
My idea was to to create one po file from all the source codes that
supply strings marked by I18N:
xgettext -dsane-backends include/sane/saneopts.h backend/epson.c \
  backend/mustek.c backend umax.c ...

That's the normal way to use gettext for other projects. We didn't do
that because of the backends separated in libraries but I think the
advanteges of one file outweigh the disadvantes.

> I suggest to do it this way:
> 
> - each backend has its own translation table
> - there is one common table for backends that do not have a translation table

Then we would only have the disadvantages of both ways but not the
advantages.

> - the frontend tries to open the backend translation table at first
> - when this fails it opens the common translation table.

That's ok. The only problem with checking the backend-specific files
first is that the common file may be newer and have better
translations.

I think everyone does it like that. I don't see a problem with
saneopts at all, because that's already used by all translated backends.

> An additional way to make sure that we do not have double
> definitions is to add a space " " at the end of the saneopts definitions.
> Then this text gets its own entry in the translation table.

I don't think that's necessary. We just won't get double definitions.
It's not possible. The double definitions are a problem that occured
because we merged saneopts.po and the backend-specific po files. If we
have only one po file, there can't be double definitions. That's one
of the reasons of my proposal :-)

I'll make that change locally for German and send a patch so everyone
can try it.

Bye,
  Henning