On Mon, 06 Sep 2004 23:09:34 +0100 Alan Cox <[EMAIL PROTECTED]> wrote:
> On Llu, 2004-09-06 at 22:50, Felix K�hling wrote: > > We want the description strings in all available languages to be > > compiled into the 3D drivers. All these macros result in a small > > XML-document which is looked up via dlopen/dlsym by the configuration > > tool (or xdriinfo as a helper for script based tools). This way > > information about available options and some human-readable > > documentation is always in sync with the drivers actually installed on > > the system. For more background on this design see > > The internationalisation system supported by all DRI supporting OS's > already deals with this itself, and includes things you don't seem to be > dealing with like character sets and the fact locales are > multi-component (eg en_GB, en_US) and with fallbacks. I'm not sure which internationalization system you're referring to. The only one I'm aware of WRT translations is gettext. And that doesn't do what we want. Gettext stores translations in external files outside the application binary. Also usually gettext is used for translations of messages output by the program itself. Our case is a bit different. The driver contains the messages and their translations, but they are not actually used by the driver. They are presented to the user by an external configuration tool. We want all translations inside the driver shared object file. This way graphical config tools have exactly one place to look for the options and their descriptions. And these descriptions are always guaranteed to be up-to-date and in sync with the driver. Since we have everything in one file we need to use the same encoding for all languages. UTF-8 is used as such a universal encoding. The fact that it's ASCII-compatible makes it easy to include as string literal in the C source code. Multi-component locales could be dealt with if someone insisted in distinguishing between, say, en_US and en_BG. It's mainly a matter of the configuration tool to deal with such locale names or use e.g. "en" as a fallback if "en_US" is not available. > > It seems strange to be reinventing the wheel > I don't think we did. Anyway, several revisions of the design were posted to dri-devel and discussed here. Noone suggested using gettext at that time. DRI developpers seem to be happy with the system as it is (someone correct me if I'm wrong) and the implementation effort was small enough to be handled by a single developper with limited time. So it doesn't seem to be such a bad thing after all. I'm not sure how much it was exposed to users (do any Xorg releases include the configuration infrastructure?). But as long as they get a nice tool that speaks their language I guess there is little incentive to change anything. Cheers, Felix | Felix K�hling <[EMAIL PROTECTED]> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idP47&alloc_id808&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
