Subject: Re: I18N & L10N proposal for GSS-API (v2u2/v3)

From: Simon Josefsson <[email-masked]>
Date: Thu, 11 May 2006 17:26:03 +0200

Nicolas Williams <[email-masked]> writes:

> 6) L10N
>
>    We might as well tackle L10N and give GSS_Display_status() an input
>    parameter indicating an RFC3066 language tag or tags to be used for
>    localization of error messages.

Isn't it better to use standard locale/gettext behaviour for l10n?

My GSS implementation support non-English error messages, and they are
returned whenever the calling application is running in a locale that
the errors are translated to.  This is how I'd expect things to work:
a function that is intended to return human readable strings should
return them in the user's language.

There is a problem if the application is a server that sends
GSS_Display_Name output over the network to a client (presumable to be
displayed to the user), but this is typically handled by having the
server set itself up to invoke GSS_Display_Name in the C locale.  Of
course, if the protocol is l18n-capable, the server would know which
proper locale to use instead.

I wouldn't be opposed to a GSS_Display_status2 that took a RFC 3066
language tag explicitly, for non-POSIX platforms, because that would
be easy to implement for me.

Thanks,
Simon

_______________________________________________
Kitten mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/kitten