Xref: utzoo comp.unix.programmer:1585 comp.lang.perl:4926 comp.std.internat:853 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!think.com!mintaka!spdcc!tauxersvilli!alphalpha!nazgul From: nazgul@alphalpha.com (Kee Hinckley) Newsgroups: comp.unix.programmer,comp.lang.perl,comp.std.internat Subject: Re: Tools for manipulating message catalogs Message-ID: <1991Apr15.030754.24877@alphalpha.com> Date: 15 Apr 91 03:07:54 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> <1991Apr12.122701.9545@dg-rtp.dg.com> Organization: asi Lines: 61 In article <1991Apr12.122701.9545@dg-rtp.dg.com> eliot@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@alfalfa.com | Send Anything... Anywhere 617/646-7703 (voice/fax) | info@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.