error info handling in MIT krb5 code
raeburn at MIT.EDU
Wed Mar 29 18:15:22 EST 2006
On Mar 29, 2006, at 17:58, Nicolas Williams wrote:
> On Wed, Mar 29, 2006 at 04:55:37PM -0500, Jeffrey Hutzelman wrote:
>> On Wednesday, March 29, 2006 04:08:13 PM -0500 Alexandra Ellwood
>> <lxs at mit.edu> wrote:
>>> We could use %s with sprintf and UTF8 strings just as easily.
>> True. But consider how this interacts with the windows event log.
> You don't localize logged strings. You localize strings shown to
If the administrator doesn't speak English, this is going to be a
problem. Ideally, we should have an easy way of switching locale for
a thread, or looking up a translation in a specified locale. Or if
the program is a server program that doesn't send text messages to
users, just use the system default locale. (For programs dealing
with two types of users, like a Kerberos KDC
> We have lots of examples of printf format string (and argument)
> localization in Solaris, but it's always done at the printf caller,
> in printf.
Sounds right, yes.
>>> there's no reason why we couldn't localize the other arguments to
>>> stringWithFormat: if that was necessary.
>> Usually you end up not wanting to do that, and instead have localized
>> versions of the result of substituting those things in. For example,
>> changing the sense of a boolean in English might just involve
>> "not " or "", but in some other language it might change the entire
>> sentence structure.
> Most of the time this is not the case. When it is you can
> structure the
> code accordingly. Solaris has to meet legal and business L10N
> requirements, and is full of examples of what I describe above.
Hm, yes, now that I think about it for a few seconds :-), the "not"
or "s" cases should be in the minority. The majority will probably
be things like "couldn't find principal %s in the database", where
you want to translate the format string and then substitute; if the
string being inserted also needs translation, then that gets done
separately. But the code should be structured so that the object
being dropped in doesn't change the sense of the message;
"foo at MIT.EDU" would be a reasonable thing to drop into the format
above, but "or policy" would not.
> but where some string arguments had to be localized I put the
> calls in the caller. To extract strings for localization I use the
> xgettext program (in /opt/sfw/bin), which can be told about functions
> other than gettext() and friends that localize string parameters).
This is pretty much the approach I expect to take, though since we
don't have much imported code, we'll probably just bite the bullet
and do the translation before calling error-info handling routines,
and not bury it inside them (except for error_message, which already
does localization on the Mac, and doesn't have any formatting
worries). Doing it right at the string literals to be translated
that way may also help us if we decide to try some interesting hack
to support systems that don't want strings, just numbers indicating
indices in a message catalog, but I'm getting ahead of myself there.
More information about the krbdev