error info handling in MIT krb5 code

Ken Raeburn raeburn at MIT.EDU
Wed Mar 29 17:48:13 EST 2006

On Mar 29, 2006, at 16:55, Jeffrey Hutzelman wrote:
>> 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.

Yep.  And any place where we refer to numbers of objects ("frob" vs  
"frobs" in English for 1 versus any other number including zero, but  
that's not even the right distinction in some other languages).

> FWIW, of Ken's choices, I think the third (multiple catalogs) seems  
> most feasible.  Unless it turns out to be _really_ easy to  
> programmatically translate format string syntax.

Well, without getting into it on N systems, I don't know how easy  
it'd be, and the answer doesn't need to be the same across  
platforms.  But simply printing strings and numbers (of various  
sizes) would almost have to be supported, along with printing them in  
an order other than the order of the argument list.  One possible  
problem might be whether we can do the formatting into a buffer and  
then use the buffer, or if the only supported interface is format-and- 

 From what I've seen so far, I don't think I need to get into it much  
right now, even for integrating the LDAP back end code.  (Dealing  
with building message catalogs and looking up translations will mean  
reviewing every place an error message is stored.  Dealing with the  
new error message storing scheme can be done by updating every  
exported function, I think.  It's less pretty, but will do until the  
former review is done.)


More information about the krbdev mailing list