Xref: utzoo comp.unix.programmer:1569 comp.lang.perl:4901 comp.std.internat:846 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!cs.utexas.edu!sun-barr!newstop!sun!amdcad!dgcad!dg-rtp!chutney!eliot From: eliot@chutney.rtp.dg.com (Topher Eliot) Newsgroups: comp.unix.programmer,comp.lang.perl,comp.std.internat Subject: Re: Tools for manipulating message catalogs Message-ID: <1991Apr12.122701.9545@dg-rtp.dg.com> Date: 12 Apr 91 12:27:01 GMT References: <1991Apr7.190119.24825@motcad.portal.com> <1991Apr8.191035.13836@alphalpha.com> <1991Apr10.122642.3991@dg-rtp.dg.com> <1991Apr11.084924.1951@alphalpha.com> Sender: usenet@dg-rtp.dg.com (Usenet Administration) Reply-To: eliot@dg-rtp.dg.com Organization: Data General Corporation, Research Triangle Park, NC Lines: 108 In article <1991Apr11.084924.1951@alphalpha.com>, nazgul@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@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@dg-rtp.dg.com {backbone}!mcnc!rti!dg-rtp!eliot Obviously, I speak for myself, not for DG.