Re: localization of client tools

["Pierangelo Masarati" <ando@sys-net.it>]

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

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

Ando.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it