[Date Prev][Date Next]
Re: localization of client tools
> At 10:49 PM 4/6/2003, Pierangelo Masarati wrote:
>>> I've made a number of commits based upon Masato's
>>> gettext patch (ITS#2410)...
>>> Basically, developers can wrap translatable
>>> strings as follows:
>>> char *str = _("translatable string");
>>> Masato has marked strings in the client tools. These
>>> need to be reviewed. Client libraries also need marking.
>>> Feel to submit patches here.
>>> Don't yet mark strings in slapd(8). Special consideration
>>> is needed here as the end-user may be in a different locale
>>> than the user running slapd(8).
>>> Masato also provided some translations. I haven't
>>> committed these as the strings he's marked need to
>>We are definitely interested in providing translations
>>in Italian, and in contributing to this development.
>>We'd like to start discussing streamlines to apply
>>localization also at the server side. I see two major
>>points: internal messages, e.g. logs, which can be
>>trivially handled as client library will, and conversation
>>with clients. In this case, the server could declare
>>what its locale is in the rood DSA entry, and we could
>>provide something like and extended op for "smart" clients
>>that can set their locale connection-wide. Comments?
> I'm think that the server, aside from having a locale for
> log messages and such, would have a "default" locale for
> messages returned over the protocol and one or more mechanisms
> which would allow a locale to be associated with a session
> (or operation?).
> One mechanism would be for the server to use the preferredLanguage
> attribute in the user's entry.
A safe default might be to use:
- any explicitly set locale, via a well defined (e.g.
a proposed standard) mechanism; or
- the one associated with the preferredLanguage attr
of the user, or
- the default of the server