error info handling in MIT krb5 code

[Nicolas Williams]

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.

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.

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

For a specific example check out how I handled L10N in ssh in Solaris:

http://cvs.opensolaris.org/source/xref/on/usr/src/cmd/ssh/

Basically, to keep diffs to OpenSSH down I moved gettext()ing of format
strings into some of the error handling functions; see do_log() in

http://cvs.opensolaris.org/source/xref/on/usr/src/cmd/ssh/libssh/common/log.c#368

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

Also, see confirm() in:

http://cvs.opensolaris.org/source/xref/on/usr/src/cmd/ssh/ssh/sshconnect.c#472

for an example of how to handle yes/no prompts.

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

See above.

Nico
--