Re: [Gnumed-devel] i18n.sql

[Karsten Hilbert]

The biggest problem I see with the current i18n.sql way of
things is that we can't have more than one foreign language
simultanously. There's three things to consider here:

1) Ian's current approach is very low on runtime overhead which is
   very good. It is client-agnostic which is good, too. It will not
   allow for multiple languages, though. Nor is switching
   languages particularly straightforward.

2) My initial scheme of translating database-level strings at
   the client allows for any number of simultaneous languages.
   It is also client-independant due to the standard gettext
   mechanism. But it incurs some overhead (the same overhead
   any client-side i18n string costs).

3) What we want is
   a) little to no client-side work
   b) client-independance
   c) multiple languages in parallel

IF we limit ourselves to one language per database we can stay
with Ian's implementation.

If not (and that is what I would suggest we want) we could try
to combine our approaches:

The basic tables would contain English standard strings.
A translation table would exist:

create table translations (
    id serial primary key,
    id_lang varchar,
    orig_str varchar,
    trans_str varchar
);

If a client wants translated strings it needs to access a view
that mirrors the original table but pulls translated strings
from the table "translations". This incurs runtime overhead
but it allows for multiple languages and is agnostic of the
client.

Any better ideas ?

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346