Tools for manipulating message catalogs

[Kee Hinckley]

In article <1991Apr10.122642.3991 at dg-rtp.dg.com> eliot at dg-rtp.dg.com writes:
>Serbo-Croation is more of a challenge).  Depending on how you distribute them
>to customers, they may or may not arrive in sync with the new executable
>code.  Customers may or may not load all the new message catalogs.  On and on.
>All in all, keeping message catalogs synchronized with programs that use
>them is a real bitch.
...
>Have I made my point clear?  Would anyone care to point out flaws in my logic?
>Does anyone still think that a tool to create a .h file out of a message
>catalog is useful?

Absolutely.  First of all you're trying to protect me from myself.
I'd rather establish conventions to do that than require it in the
code.  While you could argue that the code readability doesn't change,
your mechanism makes it more likely that people will enter the wrong
number in the code, and thus get the wrong error message.  Furthermore
it makes it impossible to reorganize the message catalog.  I have
some very large catalogs where I like to organize things (like having
all of the "File" menu items in one place).  If the numbers are
hardcoded into my program I can never do this, even when I know it's
safe.  So the readability of the message catalog gets much worse over
time.  I'm clearly on the other side of the fence from you on this
one.  Not only does my gencat create .h files, it also allows me to
create a catalog that doesn't specify any numbers at all - it generates
them automatically.

I agree that there is potential for screw ups here, particularly since
people get real annoyed everytime they modify the catalog, get new
header files and have to rebuild (that's the reason I make my gencat
compare the new and old header files and only update if the actual
values/names have changed).  I don't think that the danger here, however
outweighs the advantages.  In addition there is a way to, if not prevent
the problem, at least spot it.  Simply have a convention, as a user
of message catalogs, that messageId #1 is a version number.  Every
time you make an incompatible change to the catalog, change the version
number.  Have your application check the version number and complain
if it doesn't match.

All that said, I don't think there is so much a "flaw" in your arguments,
as a matter of preference and tradeoffs.  Even if gencat does create
header files, you are certainly under no obligation to use them, so it
seems to me we can both coexist happily (so long as I never have to
use any of your code :-).
-- 
Alfalfa Software, Inc.          |       Poste:  The EMail for Unix
nazgul at alfalfa.com              |       Send Anything... Anywhere
617/646-7703 (voice/fax)        |       info at alfalfa.com

I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.