Internationalization (was Re: IRC client)

new topic     » topic index » view thread      » older message » newer message

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.)

new topic     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu