Tools for manipulating message catalogs

[Topher Eliot]

In article <PREECE.91Apr13223807 at etude.urbana.mcd.mot.com>, preece at urbana.mcd.mot.com (Scott E. Preece) writes:
|> ...  Finally, an automatic tool would be useful for the
|> important case of the first version of a program, even if subsequent
|> versions need to maintained manually (though, actually, I think the
|> synchronization problem would be better addressed in other ways, like
|> keeping the source for the message catalog in a development environment
|> that linked it to the code and generated the new catalog as part of the
|> normal release process; I tend to think that the safest way to keep
|> things synchronized is to always reissue them together 
Sure, in an ideal world I would like to have one huge build process that
starts with my source archives for everything, and burps out a tape at the
far end that I can ship to any customer, anywhere in the world, and have it
work correctly, no matter what earlier versions of software they have on their
machine.  I have yet to see any company that actually implements such
a system, and I've worked at some of the largest computer manufacturers in
the world.  The realities of getting things translated into other languages
are horrendous.  Suppose you have a new executable and new catalog that you
have built using one of these tools that generates message numbers
automatically.  You HOPE that the numbers on existing messages haven't been
accidentally changed, but unless you build another tool to verify that, you
don't know.  You're all set to ship, complete with translated catalogs in
seven of the eight languages you support, when civil war breaks out in upper
Lithuania, and your Lithuanian translator patriotically returns to defend the
motherland :-).  You're left one language short in your catalogs.  What are
your choices?  
1) Hold all your shipments until you have a complete set of message catalogs;
2) Ship to all customers except those that use Lithuanian, and ship those
later (glad I'm not in charge of THAT operation :-);
3) Ship to everyone and hope that the old Lithuanian catalog will work ok
with the new executable;
4) Heave a sigh, and say "boy, dealing with crufty old numeric message
identifiers sure has been tacky all this time, but now we can ship this tape
even to the Lithuanians, and still sleep tonight knowing that it's very
unlikely that we've screwed up the numbers of any old messages.  Good thing
we followed Topher Eliot's advice and didn't use tools that automatically
renumber them.  Let's hire him as a high-priced consultant" :-)

I grant that you actually suggested only using the tool during the initial
development, and then switching to manual numbering.  However, I haven't seen
the tools being promoted that way, and I don't know of any tool that will
generate a .c file that is a hard-numbered version of your source, for use
after the first release.  They all assume you will continue to use the tool
during each build.

|> (surely you're
|> going to test the whole message catalog when you release a new version,
|> anyway, right? :-)).
In Norwegian?  And Portuguese? and, and?  Surely you're kidding.  I mean,
think about it -- to do such testing, you need to know both the program being
tested, and the language.  I don't know anybody who will be able to do a
really good job of testing their application in all the languages for which
message catalogs will be provided (unless, of course, "all" is just
English :-).   Doing it just once is a big task; doing it all over again
every time you release an update would be outrageously expensive.  

You may say "well, have a developer and a translator sit side by side and
run through the test suite".  What if the translator is an ocean away?
You may say "well, everyone really should have automated regression tests
anyway", but those automated tests will need catalogs listing the expected
output from the program, and we're right back where we started, i.e. trying
to keep message catalogs in sync with the executable.

So I'll say it again:  making sure that an application program and all the
different language catalogs available for it correspond correctly is a very
error-prone process, particularly when dealing with updating things in the
field.  We should do everything we can to make sure they don't get out of
sync, including gritting our teeth and using numbers instead of those oh-so-
nice automatic numbering tools.

Something just occurred to me:  how about if the automatic numbering tool
knew enough about the source archiving system (SCCS, RCS, or whatever) so
that it could compare the latest version of the catalog against all previous
versions, to make sure that no incompatibilities were being introduced?  This
might require some special flagging of messages to indicate that you really
did intend to change them, but the tool could catch egregious errors, such
as bumping all the message numbers by one.  This would go a long way towards
keeping everyone happy, wouldn't it?

-- 
Topher Eliot                           Data General DG/UX Internationalization
(919) 248-6371        62 T. W. Alexander Dr., Research Triangle Park, NC 27709
eliot at dg-rtp.dg.com                           {backbone}!mcnc!rti!dg-rtp!eliot
Obviously, I speak for myself, not for DG.