[Date Prev][Date Next] [Chronological] [Thread] [Top]

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
>> reviewed.
>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.