[sane-devel] SANE2 standard revisited: i18n

[Henning Meier-Geinitz]

Hi, 

On Thu, Dec 05, 2002 at 06:09:57PM +0100, Henning Meier-Geinitz wrote:
> http://www.meier-geinitz.de/sane/sane2/

Ok, now internationalization/localization:

| 4.2.5.1 Character Type
http://www.meier-geinitz.de/sane/sane2/0.07/doc011.html#s4.2.5

| Type SANE_Char represents a single text character or symbol. At
| present, this type maps directly to the underlying C char type
| (typically one byte). The encoding for such characters is currently
| fixed as ISO LATIN-1. Future versions of this standard may map this
| type to a wider type and allow multi-byte encodings to support
| internationalization. As a result of this, care should be taken to
| avoid the assumption that sizeof(SANE_Char)==sizeof(char). 

"Type SANE_Char represents a single text character or symbol. At
 present, this type maps directly to the underlying C char type
 (typically one byte). The encoding for such characters is fixed as
 UTF-8. Future versions of this standard may map this
 type to a wider type and allow multi-byte encodings to support
 internationalization. As a result of this, care should be taken to
 avoid the assumption that sizeof(SANE_Char)==sizeof(char). "

I'm not sure if the future extension may make sense but it doesn't
harm to keep it, does it?

I don't expect probelms here as everybody seems to use English so
converting to UTF-8 shouldn't be complicated.

| 4.2.10 Internationalization
http://www.meier-geinitz.de/sane/sane2/0.07/doc011.html#s4.2.10

| All backend texts should be written in english. Localization
| (translation of backend texts) has to be done in the frontend. To
| automatically prepare translation tables (e.g. english to german) it
| is necessary to mark the texts that shall be translated.

The description is ok, but I don't think it fits into the standard. At
least, if we want to use a SANE function to transfer the .gmo files.
I would remove the whole section and put it into po/README (some of it
is already there). Again, most of the text is backend implementation
details, not interface.

So first, a technical question: can we assume that the GNU gettext
generated .gmo files are the same on every platform? So transferring
over the net from a completely different computer works? Otherwise we
can't use them for the function approach.

Ok, here is my proposal:

Add a new function 

"4.3.14 sane_get_translation

Get a GNU gettext gmo translation file from the backend. If the
backend is able to provide a translation of options for language lang,
a pointer to the binary gmo data is returned. Otherwise, the return
value is NULL.

SANE_Byte *sane_get_translation (SANE_String_Const lang)

Backend implementation note:
Backends should contain all texts in English language. They must not
call gettext in their code themselves but only provide translation
files. Translations should be created for the members title, desc, and
string_list of SANE_Option_Descriptor."

All the rest can be in po/README. It just doesn't matter if the
backends mark the strings with SANE_I18N() or FOO(), the frontend
won't notice it anyway.

Bye,
  Henning