[sane-devel] SANE2 standard revisited: i18n

[Henning Meier-Geinitz]

Hi,

On Fri, Dec 06, 2002 at 07:33:41PM +0300, Sergey Vlasov wrote:
> On Thu, 5 Dec 2002 22:57:22 +0100
> Henning Meier-Geinitz <henning@meier-geinitz.de> wrote:
> 
> > 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.
> 
> The .gmo files are written in the byte order of the machine where they
> are generated (so there are two possible versions of the format).
> However, the GNU gettext library can load .gmo files both in the
> native and byte-swapped format (of course the native format will be
> faster).

Ok, so this doesn't seem to be a problem.

> As alwayse, there is a possibility for a format change (the .gmo
> format includes a version number field).

Yes, but all the other applications that use gettext will have the
same trouble in the case of incompatible changes. 

> However, there is another potential problem with this approach
> (translation in the frontend).  What if the backend returns some
> string which contains variable information, e.g. by using sprintf()
> internally?  In this case it is the format string which must be
> translated, not the result of formatting - but such format string
> translation can be performed only in the backend.

Good spot. I don't think it's necessary to do this in option .desc or
.title or string lists, but this one is really a problem:

> Such situation can arise with extended error messages (a backend may
> wish to include some useful diagnostic information in the returned
> string).

"Can't open device: %s (file not found)", devicename

may make sense.

The one problem that comes to my mind when using translations in the
backend, is that the frontends can't know all the translated strings
in a string list, e.g. if it wants to do some speical handling for
"Automatic Document Feeder".

There may be other reasons to don't do tarnslations in the backends
itsself (Oliver?).

Possible workaround for the string list problem:

- define an additional localized string_list in the option descriptor
  (ugly)
- get the option descriptor, unset LANG (or however to control the
  language) get it again, so the English version is also available
  (ugly, too)
- define string lists similar to options themselves: each entry has a name
  (English) and a title (localized). For setting the value of the
  option, always the name of the string list is used.
  something like:
  
  SANE_Constraint_Type constraint_type;
  union
    {
       const SANE_String_List *string_list;
       const SANE_Word *word_list;
       const SANE_Range *range;
    }
  constraint;
  
and:
typedef struct
{
  SANE_String_Const name;
  SANE_String_Const title;
}
SANE_String_List;

Are there any other library packages that have similar problems with
internationalization?

Bye,
  Henning