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-
display.
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.)
Ken
More information about the krbdev
mailing list