1. Internationalization (was Re: IRC client)
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.)
2. Re: Internationalization (was Re: IRC client)
>This set of routines _can't_ do the complete job of internationalization;
>all it can do is simplify some of the issues involved.
No prob if you document such
>Retrofitting extant programs will, naturally, be more difficult than
>writing new code with these tools in mind
Exactly my point. I'm glad you seem to have already
understood/experienced some of the points I was trying to make.
Document your intent well and all good speed.
Cheers,
Pete
3. Re: Internationalization (was Re: IRC client)
I've used a program at work that does what you want to do.
I think that feature was the only redeeming thing in the program.
It went through the program and printed a comma separated list of all of the
text.
In the first column were the words in your chosen base language with the name
of the language in the topmost position. It output this list to a file and you
went back through that file and entered the translated words in the second
column. If the word had more than one possible translation, then you just
added that word in the native language list again along with the other
translation.
The program then read the file back in and made the translations, asking which
word was the proper one in case of more than one possible match.
>From then on, the translations were in the program and you could
make them on the fly as long as you had entered them previously.
The program was (is I guess) ePLAN. It is an electrical schematic
drawing program the seems to be very big in Europe and unfortunately seems
to be gaining support in the States.
1/6/02 1:05:11 AM, jzeitlin at cyburban.com wrote:
>
>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.)
>
>
>
>
