[Date Prev][Date Next]
national language support (ITS#1201)
Sorry for not getting back to you on this sooner.... been
busy with other things. In looking at the contribution, I
think it is not readily committable. Before I attempt to hammer
specific issues, I'd like to discuss some design issues.
The code is basically provides simple wrapper to catgets(3)
based catalogs. It appears to supports caching of the catalog
descriptors, but not caching of the message strings. I
believe that for the library, we should support either no
caching or caching of the message strings. I'd prefer the
later. For the server, we need to cache message strings.
The most easy way I think of implementing this for error
messages is to simply initialize the error message array
at initialization time from the catalog. If the catalog was
not available, a static array would be used instead. A similar
approach can be used for other libraries and server messages.
I note that we might want to have a utility functions to
initialize message arrays from catalogs. These utility
functions should (eventually) support catgets(3), gettext(3),
and other key catalog APIs.
But I note that the hard problem is providing a framework for
managing the files containing the translations and producing
the appropriate catalogs for the platform. In particular,
some mechanism to avoid having multiple source files for the
same national language should be developed. That is, to derive
from language foo source file all the codeset variants of foo
(which can be derived automatically). We don't want n German
source catalogs (one per codeset) in the repository, when 1
(UTF-8) will do.
Obviously we are not the first to solve this problem... so
I am sure others have comments on how best to support national