From: pf@bilbo.bio.purdue.edu (Paul Furbacher)
Subject: Re: User-interface's language
Organization: Purdue University
Distribution: comp.lang.pascal
Date: Fri, 25 Dec 1992 09:42:11 GMT

In article <24DEC92.15463556.0031@music.mus.polymtl.ca>, CT80@music.mus.polymtl.ca (Steph) writes:
> 
> I suspect not many of you out there have this problem, but *I* do
> and maybe you guys know of a way to fix it.  I live in Quebec, and
> while the market here has a French potential, any program that
> I make would have to be in English.  Problem is, there are always
> the odd requests for the French equivalent of my software.  How
> does one go about designing a code that can be ported, easily, to
> any language?  I tried the following approach, on a BBS package
> I wrote: put all the strings as constants.  While it seemed
> feasible, I soon had to trash this idea because, on a 20,000+
> project, you soon get lost with your naming scheme of
> string-constants.
> 
> I don't really want to maintain two copies of the same software
> at the same time, ...

And that's what the concept of "application interface 
internationalization" is all about.  Because most on this group 
program PeeCees, most haven't thought about this and few 
have every paid any attention to the all but hidden exhortations
which do exist in the DOS/Windows world to "internationalize".

How do you do it? On the Mac, from the earliest days, each
file has the possibility of having two "forks": 
one for "data" and the other for "resources".  
Steve Jobs, upon forming NeXT, agreed to certain 
restrictive terms with the bean counters and lawyers at 
Apple (at least this is the legend as I've heard it). One
was to not use the same "forked" file structure.  The other
was to not create hardware with a monitor of fewer than
a million pixels, hence the large NeXT monitors
ever since the first cubes came out.  NeXTStep uses a Unix
flavored file system but essentially there are "resource"
files.  

What is a resource?  It is a code-independent collection of 
interface elements and other items. The important
concept is "code-independent".  In order to "internationalize"
your application, everything the user sees of the app
must be stored and read from resource files.  Say the user
wants to open a file.  The "open file" dialog box elements
are stored as resources -- the strings, buttons, help comments, 
whatever is visible in the dialog box, even the description of
the height, width, color, etc., of the box itself -- is held 
in the resource.  At the appropriate moment, when requested,
the application opens the resource file, reads the resource 
descriptions, translates them into the appropriate structures or
records, or better yet classes (C++) or object instances (Object
Pascal), and goes about painting them onto the screen.

If you wish to have multiple versions of your app, you simply
edit the resource files, *not* your code.  Nothing which the
user sees should be embedded in your code.  Encapsulation 
to the max.

For the Mac, since very early on, there's been a great 
program from Apple called ResEdit.  Though it's not advised
except for the most experienced user, one can alter the 
resources of any Mac application, thereby customizing 
the application for your own purposes.

Now, how do you do this in the DOS/Windows world?  Program in 
Windows and use the resource editors/compilers which are 
available. Examples are the Borland Resource WorkShop and the 
WhiteWater (bought by someone recently) rival.  

In the DOS world, there's TurboVision (Pascal/C++).  There
are several resource compiler/editors: SHAZAM is a shareware
product (TV/Pascal only?), and the Blaise TurboVision 
Development Toolkit is commercially available for both 
TV/Pascal&C++.  (You don't need them if you follow the 
examples provided with TurboVision, though the latter is
a bit more laborious.  The Blaise product has some 
limitations which become severe if your project is on
the large side.  I'm not familiar enough with SHAZAM to
comment on any of its possible limitations.  It seems 
as though the latter is the product of a more imaginative,  
perservering and responsive author.  Blaise has been 
very slow to make improvements which are necessary to 
render the product unfrustrating and productive for the 
serious developer.) 

This all means that you'll have to upgrade your
programming tools, given that you  currently own ones  
which have not introduced the idea of internationalization
to you in their manuals.

Good programming practice demands that the intelligent project
managers design programs based on using resources.  Increasingly, 
except for very narrow niche applications perhaps, 
internationlization will be a prerequisite.

PF