Tools for manipulating message catalogs

[Topher Eliot]

In article <1991Apr11.084924.1951 at alphalpha.com>, nazgul at alphalpha.com (Kee Hinckley) writes:
|> Absolutely.  First of all you're trying to protect me from myself.
No, I'm trying to protect other people who aren't experienced in the pains of
distributing message catalogs from the mistakes your* tools might tempt them to
make.  Obviously anybody with enough experience with internationalization
to create new tools for it isn't going to make foolish mistakes.  But others
may well.

*It was you who posted the note about the new tools, right?

|> 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.  
Yes, they may be more likely to get it wrong once, during development, where
it will be found during an initial pass of testing.  But then it will be gotten
right, and it will then stay right.  Your system makes it easier for the
numbers to become wrong later on, in ways that are harder to detect and keep
track of.

|> Furthermore
|> it makes it impossible to reorganize the message catalog.  
Nothing is impossible.  My approach makes it appropriately difficult.  You
SHOULD be reluctant to reorganize your catalog.

|> I have
|> some very large catalogs where I like to organize things (like having
|> all of the "File" menu items in one place).  
I would have thought that message sets would fill this need very nicely.
Note that everywhere that I said "add new messages only to the end of the
catalog", I really should have said "add new messages only to the ends of
sets, and add new sets only to the end of the catalog".

...
|> 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.
So instead of having to type in numbers, you have to type in symbolic names.
Why is this any easier?  Symbolic names are an advantage when you want to be
able to change the underlying value later on.  I claim that with message
numbers, you shouldn't change those values!  These numbers should be CONSTANTS!

|> 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 ...
You won't hear any complaints from me about rebuilding.  That isn't my point.
But your "rebuild the .h file only if necessary" feature is a nice touch.

...
|> 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.
In other words, protect yourself from yourself.  Isn't this what you were
complaining about?  Why build a tool that makes a certain class of errors
more likeley, and then invent a convention to try to head off those errors?
Do you really think that the class of programmers that are likely to screw
up message catalogs is the same class of programmers that will diligently
put this checking code into their applications?  I don't.

Moreover, such a convention would make it so that if the developer added
one message to the end of a catalog, and distributed new executables and
new English-language catalogs on January 1st, and the Serbo-Croation
catalog didn't get distributed until March 1st, the Serbo-Croations would
not get to use new new application and their own language catalog for two
months.  With my approach, they would only see the one new message in English
for those two months.  The old Serbo-Croation catalog would serve just fine
for all the other messages.

|> 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 :-).
Ah, but who will maintain the code that you have written this way?  I assert
that code developed using my approach will be much less of a headache to
maintain and support than will be code developed and maintained using your
tools.  Yes, the first time around, during development, your approach is
easier to use.  Once that first translated catalog goes out to customers,
my approach is much more robust.


Meanwhile, erik at srava.sra.co.jp (Erik M. van der Poel) says:
|> Kee Hinckley writes:
|> > 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.
|> 
|> Instead of treating the symptoms, we should try to cure the disease. 
|> Using numbers for the message ids was a bad idea in the first place. 
|> (Thank goodness XPG3 and AT&T's specs are not International
|> Standards.)
|> 
|> Wouldn't it be possible to create a reasonably efficient
|> implementation using hashing and caching with symbolic names instead
|> of numeric ids? Then we can add/delete/modify messages at will. We
|> should leave numbering and counting to the computer.

This sounds even better to me.  After I posted my note, I heard that Uniforum
has advanced a proposal exactly along these lines.  Does anyone have any
specifics on 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.