Xref: utzoo comp.unix.programmer:1620 comp.lang.perl:5003 comp.std.internat:867 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!usc!jarthur!uunet!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: <1991Apr19.130632.17861@dg-rtp.dg.com> Date: 19 Apr 91 13:06:32 GMT References: <1991Apr7.190119.24825@motcad.portal.com> <1991Apr15.170901.18836@dg-rtp.dg.com> <1991Apr17.053943.6263@alphalpha.com> Sender: usenet@dg-rtp.dg.com (Usenet Administration) Reply-To: eliot@dg-rtp.dg.com Distribution: comp Organization: Data General Corporation, Research Triangle Park, NC Lines: 59 In article <1991Apr17.053943.6263@alphalpha.com>, nazgul@alphalpha.com (Kee Hinckley) writes: |> How about if I add a feature to the gencat which checks to see if the |> message numbers have change incompabibly? And if so it issues a warning? |> I think it's doable, and I've pretty much been convinced it's useful. |> |> >Something just occurred to me: how about if the automatic numbering tool |> >knew enough about the source archiving system (SCCS, RCS, or whatever) so |> >that it could compare the latest version of the catalog against all previous |> >versions, to make sure that no incompatibilities were being introduced? This |> This'll get me for replying before reading everything. Anyway, you could |> do it there, but I think doing it with the message catalog iself would |> be sufficient (and certainly easier). Easier to implement, absolutely. Sufficient? I guess it depends on how you handle your builds, etc. Such a feature would definitely be good, but one could still lose track of an incompatible change if one were careless in the development process. Someone sent me some mail with a suggestion that I thought was good. I was waiting to see it posted, but I'll go ahead and do it. The suggestion was that the input catalog should look like: $set 1 BASEMSGS 1 ERRMSG "Error in application foo:" 2 WARNMSG "Warning:" and so on. From this one could generate a .h file, and allow the .c file to use the symbolic values (BASEMSGS, ERRMSG, WARNMSG, etc), and yet still avoid the danger of accidental renumbering. Of course if you WANT automatic renumbering then this approach isn't for you. But with this approach manual renumbering is much easier than with my original "NO SYMBOLIC IDENTIFIERS" gospel. Renumbering would be a 5-minute editing job, all in one file. This idea seems pretty straightforward to implement, and more robust than the approach of trying to automatically detect incompatible changes and issue warning messages. So, far, of all the ideas I've seen, I like this one best. Does anyone see anything wrong with it? Various people have said things here and in private mail that, in my mind, essentially pooh-pooh the difficulties of keeping executables and translated message catalogs in sync on customers' machines. Well, what can I say. _I_ think it's a hard problem. At the other end of the spectrum, some people have suggested very strong mechanisms to rigidly enforce such coordination -- if you don't have the right message catalog, you can't run. This is certainly the safest approach to solving this particular set of problems, but my feeling is that it would be overruled the first time a fatal bug was found in an application, which had to be fixed immediately, but translated message catalogs weren't available yet. I try to use policies that are flexible enough to bend when they need to, yet will still do you some good when bent. The absolute-synchronization rule is too all-or-nothing for my taste. -- 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.