Internationalization (was Re: IRC client)
- Posted by jzeitlin at cyburban.com Jan 05, 2002
- 428 views
On Sat, 05 Jan 2002 21:17:33 -0800, petelomax at blueyonder.co.uk wrote: >On Sat, 05 Jan 2002 17:48:56 -0500, you wrote: >>, in theory, all one would have to do to release a French >>and a German version of a program would be to ship a different string >>resources file. >Obviously you intend something quite simple which would probably be >fine for smaller applications, so don't let me put you off, too much. >There follows a bit of a rant which should probably just have said "Be >aware this is fine for whole sentences, help text, etc, but single >word field and column labels will often still need editing by hand." >I once had the misfortune to "work" on such a system. Something quite >innocent - order springs to mind - can cause major headaches. The >English dictionary (the OED) may have about 20 definitions of the >word, but say in German the overlap is most definitely not 1:1. For >example German for sales order is I believe completely different to >purchase order, and for that matter a confirmed, held, delivered, or >invoiced order. The point is that where the English version has a >field or column heading of "Order", somehow you need to specify which >of the fifteen or so entries for "Order" in the German dictionary / >"string resources file" it corresponds to. Nononono! That's equivalent to the program doing the language translation, which I explicitly am _not_ doing. What I'm doing is making it possible to have the English version say "Good Day" and the German version say "Guten Tag", without having to recompile; just ship a different "language.dat" file. The language.dat file contains only the specific strings that are used in the program, not a general translation dictionary. _You_, the author, are responsible for the correctness of the translation. [the rest of yours deleted; I can address most of the issues in my explanation] This set of routines _can't_ do the complete job of internationalization; all it can do is simplify some of the issues involved. It expects the use of certain techniques in code and the avoidance of others. It can't overrule the built-in OS routines unless the OS allows it; basically, what you will do is write code that looks like HELLO = 1 puts(1,getmsg(HELLO)) instead of puts(1,"Hello!") and you'll also have a file that contains a line like n1=Hello! in the English version, and n1=¡Hola! in the Spanish version. And all you'll have to do is ship a different file with the text in it instead of recompiling the program in the different language. Like I said, it won't do the translation; it will make it easier for you to write the code to accommodate multiple languages. I've already got a "plan of attack" for handling printf and sprintf where the order of the parameters might want to change; if you use my library, you won't have to worry about that; your strings will tell the routines which parameters to use in what order. Full documentation will be included explaining what needs to be changed in the code you write, and I'll even include a program that will parse your code and make _some_ of the changes automatically. As I said, my code can't do the _complete_ job, it can only do _some_ of the job, and make it easier for you to do other parts of it. And if the OS doesn't let you use certain techniques, then those parts of my library that might depend on those techniques won't be helpful to you. Yes, it will work best on small programs. But I used to work on an OS and with applications that were using this technique almost exclusively - and they weren't all small applications, either - a Lotus-compatible spreadsheet, all of the command-line utilities (it was a pre-GUI environment), a word processor, and I don't recall what-all else - but it was _heavily_ used, and did not seem to be an impediment to the writing of the programs. Retrofitting extant programs will, naturally, be more difficult than writing new code with these tools in mind - but that's always the case when new tools become available. -- Jeff Zeitlin jzeitlin at cyburban.com (ILink: news without the abuse. Ask via email.)