error info handling in MIT krb5 code

[Ken Raeburn]

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

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,  
> not
> in printf.

Sounds right, yes.

>>> And
>>> 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  
>> substituting
>> "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  
> gettext()
> calls in the caller.  To extract strings for localization I use the  
> GNU
> 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.

Ken