On Thu, 16 Feb 2006 16:39:38 -0500 (EST) David Korn wrote:
> I believe that there are nmake rules for updating the message
> catalogs, but since Glenn Fowler has been doing this I don't
> have any experience with it.
collecting the C local strings is a 2 stage process
stage one mimics cc/ld with a command called msgcc
nmake rules grab and modify the %c=>%.o and %.o=>a.out rules
on the fly to instead "compile" with msgcc to generate .mso (.o)
and .msg (a.out) files -- this is done by "nmake msgcat" in
the top build dir
then a msgadmin command collects the .msg files into numbered
message catalogs -- messages are replaced when possble to maintain
message number consistency from release to release, otherwise
new message are added to the end of the catalogs and unused message
numbers silently retire
a third stage coordinates the translation of new messages from
the C locale to the locales of interest -- at one time I had
automated this, but I quickly got on altavistas black list,
so I ceased for fear of blacklisting all of at&t :)
those automatic translations were pretty goofy anyway
the ln(1) page ended up describing a golf course (links) auf deutsch
so to validate the whole process we have and post { chef fudd piglatin valley }
message locales
the theme here is we probably have a tool to automate
the boring tasks of i18n (except for the final high quality translation)
the bonus is that our i18n enabled source doesn't look like it is
because, like dgk said, we use C locale strings instead of
message numbers, and the message printing function uses these
strings to look up the numbers in the message catalogs
solaris gettext() could be wedged into that one library function,
leaving the rest of the code intact
