Xref: utzoo comp.unix.programmer:1584 comp.lang.perl:4923 comp.std.internat:851 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!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: <1991Apr15.170901.18836@dg-rtp.dg.com> Date: 15 Apr 91 17:09:01 GMT References: <1991Apr7.190119.24825@motcad.portal.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: 83 In article , preece@urbana.mcd.mot.com (Scott E. Preece) writes: |> ... Finally, an automatic tool would be useful for the |> important case of the first version of a program, even if subsequent |> versions need to maintained manually (though, actually, I think the |> synchronization problem would be better addressed in other ways, like |> keeping the source for the message catalog in a development environment |> that linked it to the code and generated the new catalog as part of the |> normal release process; I tend to think that the safest way to keep |> things synchronized is to always reissue them together Sure, in an ideal world I would like to have one huge build process that starts with my source archives for everything, and burps out a tape at the far end that I can ship to any customer, anywhere in the world, and have it work correctly, no matter what earlier versions of software they have on their machine. I have yet to see any company that actually implements such a system, and I've worked at some of the largest computer manufacturers in the world. The realities of getting things translated into other languages are horrendous. Suppose you have a new executable and new catalog that you have built using one of these tools that generates message numbers automatically. You HOPE that the numbers on existing messages haven't been accidentally changed, but unless you build another tool to verify that, you don't know. You're all set to ship, complete with translated catalogs in seven of the eight languages you support, when civil war breaks out in upper Lithuania, and your Lithuanian translator patriotically returns to defend the motherland :-). You're left one language short in your catalogs. What are your choices? 1) Hold all your shipments until you have a complete set of message catalogs; 2) Ship to all customers except those that use Lithuanian, and ship those later (glad I'm not in charge of THAT operation :-); 3) Ship to everyone and hope that the old Lithuanian catalog will work ok with the new executable; 4) Heave a sigh, and say "boy, dealing with crufty old numeric message identifiers sure has been tacky all this time, but now we can ship this tape even to the Lithuanians, and still sleep tonight knowing that it's very unlikely that we've screwed up the numbers of any old messages. Good thing we followed Topher Eliot's advice and didn't use tools that automatically renumber them. Let's hire him as a high-priced consultant" :-) I grant that you actually suggested only using the tool during the initial development, and then switching to manual numbering. However, I haven't seen the tools being promoted that way, and I don't know of any tool that will generate a .c file that is a hard-numbered version of your source, for use after the first release. They all assume you will continue to use the tool during each build. |> (surely you're |> going to test the whole message catalog when you release a new version, |> anyway, right? :-)). In Norwegian? And Portuguese? and, and? Surely you're kidding. I mean, think about it -- to do such testing, you need to know both the program being tested, and the language. I don't know anybody who will be able to do a really good job of testing their application in all the languages for which message catalogs will be provided (unless, of course, "all" is just English :-). Doing it just once is a big task; doing it all over again every time you release an update would be outrageously expensive. You may say "well, have a developer and a translator sit side by side and run through the test suite". What if the translator is an ocean away? You may say "well, everyone really should have automated regression tests anyway", but those automated tests will need catalogs listing the expected output from the program, and we're right back where we started, i.e. trying to keep message catalogs in sync with the executable. So I'll say it again: making sure that an application program and all the different language catalogs available for it correspond correctly is a very error-prone process, particularly when dealing with updating things in the field. We should do everything we can to make sure they don't get out of sync, including gritting our teeth and using numbers instead of those oh-so- nice automatic numbering tools. 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 might require some special flagging of messages to indicate that you really did intend to change them, but the tool could catch egregious errors, such as bumping all the message numbers by one. This would go a long way towards keeping everyone happy, wouldn't 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.