[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