Client localization design issues

[ghudson@MIT.EDU]

I'm starting to look into adding client localization support using
gettext, and I've identified five things to talk about.

1. Where to localize com_err messages

Solaris Kerberos and Heimdal both localize com_err messages in
error_message() in their versions of the com_err library.  A caveat
here is that at least on Debian and Ubuntu, MIT krb5 is built with the
e2fsprogs com_err, which has no localization support that I can see.

An alternative is to leave libcom_err alone and call gettext() in
krb5_get_error_message().  This wouldn't localize programs which call
com_err() without the a com_err hook (something we should maybe
provide in libkrb5), but extended error messages don't affect those
programs either, so they should be fixed anyway.

(Extended error messages need to be localized where they are
generated, of course, since you have to get to them before they are
formatted.)

2. Text domains for com_err messages

If error_message() does localization, it will need to do a
dgettext(message, domain) for some value of domain.

In Solaris, the text domain is always some hardcoded krb5 domain; in
fact, the Solaris Kerberos com_err is entirely krb5-specific.

In Heimdal, com_err constructs a domain based on the error table base,
following the format "heim_com_err%d".  This is a little friendlier to
the intent of com_err, but since the name is Heimdal-specific, it's
not that friendly.  I'm actually not sure how to reconcile the idea of
a global com_err ecosystem with the fact that Heimdal and krb5 provide
different versions of the same error tables.  If the text domain for
the Heimdal and MIT krb5 error tables were the same (say,
"com_err-1765328384") then that would present another obstacle to
installing both libraries on the same system.

3. Generating pot files for .et files

This is a pretty mundane problem.  Solaris and Heimdal both approach
it by running xgettext over the generated .c files (Heimdal at build
time using some "find" invocations, Solaris by checking generated
error tables into version control).  An alternative would be teaching
compile_et how to output pot files.

4. Macros for markup

The Gnu gettext documentation suggests _() for translating a string
and N_() to mark a string for xgettext which will be translated
elsewhere.  Heimdal uses N_() for translating and NP_() for
gettext_noop.  Is Heimdal an outlier here, or has the convention
drifted?

(Of course, _() probably impinges upon the ANSI C reserved namespace,
but it's such a common thing to do that no platform is likely to
create a problem for it.)

5. Tools to help mark up strings in the source tree

Does anyone have tools for identifying unmarked strings?  Otherwise
I'll have to write a script, I guess.