i18n (was: Re: Conclusions and a compact list of requirements for deconf-spec)

[Philip Van Hoof]

On Sat, 2005-12-10 at 15:57 +0100, Christian Neumair wrote:
> On Sa, 2005-12-10 at 12:44 +0100, Philip Van Hoof wrote:
> > Since my holiday starts, chances are high that I might work on some of
> > my idea's. Including deconf-spec and it's futuristic (most of you guys
> > call futuristic things "vaporware") implementation.
> 
> The whole i18n part of the spec doesn't look very well thought-out. I
> doubt it is wise to cross-reference the translated schemas, and even
> referencing one for a given key seems to be wrong.

Correct. It has been marked as incorrect at this moment. I haven't put a
lot time into getting i18n correct. 

The main issue with i18n is that if you embed the translations in the
XML files, you'll have to parse that. This introduces a memory overhead
(all the unused translations are also loaded in memory). Therefore it's
important to keep the translations in different files.

Everybody is encouraged to create a diff to fix the fact that at this
moment it isn't well thought-out.

> The problem with multiple schemas is that we replicate the structural
> information of the schemas file, thus possibly having inconsistencies
> among multiple localized variants of the same schema.


> I'm convinced that the best method would be to allow all schemas to
> specify a particular translation domain, which can then be used by the
> implementation to figure out the correct (implementation-dependant)
> string. We'd typically use gettext, i.e. the server looks up a
> particular string in a particular gettext catalog with a given language.
> This implies also must be description getters for particular languages:

> GetDescription - in: language (*) - out: long_description, out:
> short_description

> I don't think it is important to provide a mechanism for listing all
> available languages for a particular schema or key, nor to be able to
> detect whether a short or long description exists in a particular
> locale. After all, these strings are used in GUIs and query utilities
> and I don't see any reason to introspect this information. If people
> demand for it, we might have to add it later.
> 
> (*) (as returned by setlocale (LC_MESSAGES, NULL)). I'm not sure whether
> there is a spec describing the valid locales. man setlocale just
> mentions a typical form that involves some ISO standards.

You're encouraged to build a diff ;-)

However. I'll mark your comment as important in my E-mail software, and
will certainly take a look at it when I decide to fix this in the
current proposed specification.

-- 
Philip Van Hoof, software developer at x-tend
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
work: vanhoof at x-tend dot be
http://www.pvanhoof.be - http://www.x-tend.be