🚀 go-pugleaf

Here are the consolidated answers to the original question from
Minh (Minh_T._Le.ESCP10@xerox.com):

     I just bought a book SW Internationalization and Localization by Uren et al and
     studied a little bit about he topic.  In Chapter4, it talks about three
     different design issues:
     1) Compile-time Internationalization
     2) Run-time internationalization
     3) Link-time internationalization.
     One comment in the book indicates that large UNIX houses tend to use run-time
     language binding.

     I'd like to know a little more about the differences as well as the advantages
     and disadvantanges among the three. Could anyone, who is familiar with the
     topic give some help?


Jeff
INSOFT-L List Manager

*========================================================================*
 Jeff Bowyer                         EMail:
 Computing Center		     jbowyer@cis.vutbr.cz
 Technical University of Brno
 Udolni 19, 602 00 BRNO
 Czech Republic
*========================================================================*


Sender: Francis Ng <francisn@hpwarht.wal.hp.com>
        Hewlett-Packard Company

The book by Dave Taylor, Global Software - Developing Application for the
International Market, published by Springer-Verlag, discusses the three
type of i18n in detail. It also contains good pointers for more information
on the subject.


Sender: Jon Wtte (d88-jwa@nada.kth.se)

I think what you meant is "localization" not "i18n"

> 1) Compile-time Internationalization

Not recommended since you generally cannot let a third party
do localization.

> 2) Run-time internationalization

Cool but can cause some problems - for instance, what language do
you use for error messages if you can't find the vocabulary file?

> 3) Link-time internationalization

Workable but not ideal. A cross between 2 and 3 is what we use;
we put all vocabulary and graphics items in a separate resource
file, and the first thing our app does when it starts is look
for a file of this kind (the Mac has a typed file system!) and
load it. If you want to switch languages, you quit the program,
drop in the other language file and remove the first and re-launch.
(We use the first one we find, so having plenty and renaming them
would work, too)

However, you should not confuse the above (localization, really)
with "real" internationalization which means that regardless of
the locale of language and graphics, your program can work with a
lot of different languages/script systems, preferrably at the same
time. This, of course, requires some coding effort and OS support.


Sender: Dave Taylor (taylor@mentor.cc.purdue.edu)
        Department of Education

I humbly suggest you that you find and read a copy of:

	Taylor, Dave (1992). _Global_Software_. Springer-Verlag:New York.

It has an extremely extensive discussion -- with many examples -- of
just this question.


Sender: Jean-Pierre Trevisani (clsib21!jpt@BBN.COM)
        Project Leader, Geac-CLSI Inc.

The biggest difference between run-time and the other two is that run-time
can be changed after the product has been shipped and is installed.  Once
you have compiled or linked, that's it. (well, I am sure there are ways but
IMO not as simple).

We use run-time.  That's because we have a multi-user (UNIX) product which
must support up to 20 languages _CONCURRENTLY_. I.e a user might be
running in English, the next one in French and yet another in Spanish.
This on the same executable, on the same box.  If we were to include all the
languages inside the executable and bind at compile-time, we would increase
the size of the executable by 6Mb!  We also allow our users to modify
absolutely all the text on the screen, and this, in each of the languages.

I personally do not like compile or link time internationalization simply
because I do not think it is flexible enough. (anyone is welcome to disagree).
It is my experience that little errors slip through more often than not
and with run-time binding, fixing them is trivial.