Tools for manipulating message catalogs

[Topher Eliot]

In article <1991Apr17.053943.6263 at alphalpha.com>, nazgul at alphalpha.com (Kee Hinckley) writes:
|> How about if I add a feature to the gencat which checks to see if the
|> message numbers have change incompabibly? And if so it issues a warning?
|> I think it's doable, and I've pretty much been convinced it's useful.
|> 
|> >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
|> This'll get me for replying before reading everything.  Anyway, you could
|> do it there, but I think doing it with the message catalog iself would
|> be sufficient (and certainly easier).
Easier to implement, absolutely.  Sufficient?  I guess it depends on how you
handle your builds, etc.  Such a feature would definitely be good, but one
could still lose track of an incompatible change if one were careless in the
development process.


Someone sent me some mail with a suggestion that I thought was good.  I was
waiting to see it posted, but I'll go ahead and do it.  The suggestion was
that the input catalog should look like:

$set 1 BASEMSGS
1	ERRMSG		"Error in application foo:"
2	WARNMSG		"Warning:"

and so on.  From this one could generate a .h file, and allow the .c file to
use the symbolic values (BASEMSGS, ERRMSG, WARNMSG, etc), and yet still avoid
the danger of accidental renumbering.  Of course if you WANT automatic
renumbering then this approach isn't for you.  But with this approach manual
renumbering is much easier than with my original "NO SYMBOLIC IDENTIFIERS"
gospel.  Renumbering would be a 5-minute editing job, all in one file.  This
idea seems pretty straightforward to implement, and more robust than the
approach of trying to automatically detect incompatible changes and issue
warning messages.

So, far, of all the ideas I've seen, I like this one best.  Does anyone see
anything wrong with it?

Various people have said things here and in private mail that, in my mind,
essentially pooh-pooh the difficulties of keeping executables and translated
message catalogs in sync on customers' machines.  Well, what can I say.  _I_
think it's a hard problem.

At the other end of the spectrum, some people have suggested very strong
mechanisms to rigidly enforce such coordination -- if you don't have the
right message catalog, you can't run.  This is certainly the safest approach
to solving this particular set of problems, but my feeling is that it would
be overruled the first time a fatal bug was found in an application, which had
to be fixed immediately, but translated message catalogs weren't available yet.
I try to use policies that are flexible enough to bend when they need to, yet
will still do you some good when bent.  The absolute-synchronization rule is
too all-or-nothing for my taste.

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