XErrorDB in a modular world

[Soeren Sandmann]

Alan Coopersmith wrote:

>> The other issue we should think about more seriously is the I18N support
>> of this facility; error messages should be able to be localized.
>
>
> Right - I thought about that as well as long as we're changing the code.
> For most of XErrorDB, localization doesn't make sense - it's just a
> mapping of request & error codes to the protocol names, and localizing
> those would just make it harder to figure out what's going on.   There
> are some text messages in there that should be localized though, but
> only for a few
>
> I was thinking the lookup path for messages for each extension/protocol
> would be something like:
>     <prefix>/lib/X11/ErrorDB/<language>/<extension>
>     <prefix>/lib/X11/ErrorDB/C/<extension>
>
> And what's now XErrorDB would become <prefix>/lib/X11/ErrorDB/C/X11
> (possibly with a symlink to that left for minimal backwards 
> compatibility with any clients linked with old libX11's).

I would prefer to not deal with this problem until after 7.0. For now we 
can just add the
necessary lines to XErrorDB and be done with it.

This does mean that people will have to ship XErrorDB's containing error 
messages for extensions
they may not want to ship, but I don't think it's that big of a deal. 
Changing the code
as little as possible is nice as long as we are symlinking between the 
trees.

I do agree though that we should fix this for 7.1. Another possibility 
than having extensions
ship their own files might be to add a new public call to Xlb:

    XRegisterExtensionCodes (const TableOfCodes *codes)

that extensions would call at initialization time.  The table of codes 
could be required to
exist at all times so that it would be shared between all applications 
and never paged into
memory unless it was needed.

Another long term possibility would be to add the ability to have the 
server report the
messages back, although for compatibility reasons an XErrorDB file would 
still be needed.



Søren