Tools for manipulating message catalogs

[Kee Hinckley]

In article <1991Apr12.122701.9545 at dg-rtp.dg.com> eliot at dg-rtp.dg.com writes:
>*It was you who posted the note about the new tools, right?
I plead guilty :-).

>|> all of the "File" menu items in one place).  
>I would have thought that message sets would fill this need very nicely.
Quite right.  I hadn't considered using them at that level of granularity.

>|> 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
Not really.  The difference is that this is a restriction I can institute
if I feel it is needed, as opposed to one forced on me by the implementation
of the tools.  But if this were the only issue I wouldn't mind.

>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.
I can't argue with this.

>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.
This is an interesting point, because it makes me realize another way
that people can misuse symbolic numbers.  You see it turns out that they
are terifficly convenient to use as identifiers for other things.  For
instance I use them to identify my menubutton objects.  Based on the
identifier I execute the appropriate action.  If I had to do a string
compare I wouldn't do it that way.  But furthermore, I use the identifier
(plus a fixed count) to find the accelerator, mnemonic and string-form
of the accelerator in the catalog.  This leads to an unfortunate side effect,
namely, there are no fallback strings for those values.  Without the
catalog the program is usable, but not full-function.  So yes, you are right;
numeric identifiers can be abused.  I won't know whether the tradeoffs
I'm making are worth it until we start shipping lots of different language
versions - but it's definitely something to think about.

>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
I'm not sure, I still think it's too easy to get burned by the runtime
typing.  How do you verify that all of your strings in fact correspond
to message catalog symbols?  That issue and the speed/memory issues are
my major concerns.

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