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 _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
