error info handling in MIT krb5 code

[Nicolas Williams]

On Wed, Mar 29, 2006 at 06:15:22PM -0500, Ken Raeburn wrote:
> 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

Vendors need to be able to understand the log entries too, and by and
large they'll understand English easily.

The problem here is that log files and logging protocols store/move
post-formatting strings, and so lose the ability to re-localize for
different viewers.

Perhaps this is an argument for redesigning log files, facilities and
protocols, but that's way beyond what MIT can do in the scope of krb5 :/
I'm sure :)

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

The way we handle exceptional cases is this: the localization team will
file bugs when they run into strings that are difficult to localize, and
engineering will fix them.

Because the exceptions are rare this approach works rather well.

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

Minimizing changes for vendors who've integrated MIT krb5 source and
done some localization work already would be nice though...  :^)

Nico
--