[sane-devel] SANE i18n: only one translation file per language?
Henning Meier-Geinitz
henning at meier-geinitz.de
Sat Nov 30 11:19:29 GMT 2002
Hi,
What about the following proposal for SANE1 (but see comment for SANE2
below):
We only use one translation file per language that includes all
translations from all the backends. E.g. sane-backends.de.po.
Currently, we use one file per backend per language and an additional
saneopts.??.po which translates saneopts.h.
Advantages:
- easier build system
- no tricks with concatenating saneopts.??.po and backend.??.po
- no charset mismatches
- smaller .mo size (because saneopts.??.po is only used once per
language)
- it's easier to add new translations
- no need to duplicate the same translations in every backend
- even backends that are not translated can use the translations
from saneopts (and other backends)
Disadvantages:
- frontends have to be changed. But I think it's possible to check for
"sane-backends" first, then check _("") for the string
"sane-backends", and if not found, load "sane-backendname" as before.
Or maybe the other way round, if this is preferred. So new frontends
work with both old and new backends.
- backend translaters have to agree about a translation, if a word is
used in different backends. E.g. "Gray" = "Grau" or "Graustufen".
- Half-translated backends. Some options may be translated, others
aren't. On the other hand, it's not a new situation because e.g. xsane
itsself is tranlated and the backend isn't so you got mixed messages
anyway.
In SANE2, the backends would usually transfer the general sane-backends
translation file. But the backend could also decide to use its own
one, if the author doesn't like the general one.
Opinions? Other advantages/disadvantages?
Bye,
Henning
More information about the sane-devel
mailing list