[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.
Kurt