Xref: utzoo comp.sys.ibm.pc:37062 comp.sys.atari.st:20849
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!gem.mps.ohio-state.edu!usc!hacgate!ashtate!dbase!dveditz
From: dveditz@dbase.UUCP (Dan Veditz)
Newsgroups: comp.sys.ibm.pc,comp.sys.atari.st
Subject: Re: More Internationalization of Software
Message-ID: <285@dbase.UUCP>
Date: 26 Oct 89 16:42:32 GMT
References: <9995@cadnetix.COM>
Reply-To: dveditz@dbase.UUCP (Dan Veditz)
Organization: Ashton Tate Devlopment Center Glendale, Calif.
Lines: 50

In article <9995@cadnetix.COM> terrell@cadnetix.COM () asks:
>   How does documentation differ in Europe?  Do US software developers go
>   to the trouble of converting to British spelling?  Do British users
>   resent it when they don't?  Or perhaps the users don't care?

I have been involved with product translation tools the last six
years.  In the companies I've worked for all actual translation
was done by subsidiaries or branch offices in the target country.

In most countries everything has to be translated.  England is a special
case because we almost write the same language.  It's up to whoever is
in charge of marketing for England to decide how important it is.  I know
we translated it in the first company I worked for, but we sold to banks
and other industries that might be more concerned than buyers of home PC
software with how "proper" things are.

>   Does the European user community tend to get US products before their 
>   counterparts in the US?  

Not where I've worked.

At one company the tools, text resource files and documentation were 
not turned over until the product was completed.  European versions of
a 1.0 release were several months to a year behind the US release, but 
versions > 1.0 were usually quicker because only the changed text needs 
to be translated (anything unchanged can be brought forward from the 
previous release).  

In another company updates to the textual items and tools were released 
periodically as they changed during development, so the European releases 
were only a month or two behind the US.  

As an important note, from a developers point of view textual translations
are easy.  The hard stuff is dealing with different sizes of paper, different
date formats, different currency formats, variable length currency symbols,
decimal notation (many European countries reverse the US period and comma)
and many other *format* changes.  Any routines dealing with these things 
must be general and switchable, either as compile time options, or better,
as user configurable options.

My personal favorite was a mainframe-based office automation system that
could run in any of up to 19 languages at once.  Each user specified which
of the loaded languages he or she wanted to use, and could change it at
any time.  Multiple languages sure ate up a lot of disk, though.

As yet another aside, some Canadian government contracts we bid on *required*
a system that was switchable between English and French.  If your company
has any aims in this direction, keep this in mind.

-Daniel Veditz