J.P.
X.Net, Inc. is a Globalization consulting company. We often get involved
with a companies second attempt. It seems so easy just to localize your
product and you are ready for the world market. This is an area where
people have no experience and it seems like they have to get burned to
learn.
It is like people who have never learned a foreign language don't understand
that there are ideas that just don't translate. They don't understand that
their languages express ideas and concepts foreign to English.
The classic example is Windows. Originally Microsoft developed each new
release in Redmond and each country developed a localized version. So when
Windows 3.1 came out each country had it own version. Each version was
different. The Japanese versions requires a special DOS, the Greek version
would not support special symbols, the Chinese supports "system" for
printers but the Japanese did not, Thai Windows was a partial implementation
mostly help word break logic. You had to include the help code in your
applications to get them to work properly.
There were long delays some times years. Windows for Workgroups did not
come out for many languages including some major languages.
They saw the problem coming and designed NT using Unicode. Great idea but
Unicode alone was not enough. There still localized the versions. However,
now the consistency was improved. NT was NT was NT.
The next step was to change the development mindset to develop globalized
code. This came with Win 95. Unfortunately MS was competing with IBM's
OS/2 at the time and wanted good performance on a 4MB system. While they
use Unicode internally they dropped Unicode support from the user API. But
this did provide an important goal. Single source and three code bases for
all languages with almost simultaneous release.
This has been carried over to the NT product so the with the multi-language
version of Windows NT you can change languages of the operation system on
the fly.
Netscape is another example. They worked on Netscape to try to add
localization features but could never get it to work as well as IE. Now
they have totally rewritten Netscape 6.0 in Unicode to compete with IE 5.5.
Writing a program to use a code page is like hand building a car. If you
just make one then it is probably the best choice. Going to Unicode is like
setting up an assembly line. If you provide a multi code page version that
each new locale for each release requires some program change. With a fully
globalized Unicode solution such changes are outside of the program.
Localization is a matter of message files, resources, etc. nothing else.
The biggest payback is support. You run a single code image. Bugs are far
easier to reproduce. Code becomes supportable.
To give you a couple of examples:
1) I was installing the Microsoft US MSVC++ compiler on Korean NT 4.0.
However The MSVC service pack applies fixes to both the product and the
underlying NT OS. I could not fid a service pack that would work.
2) I just upgraded a client to Unicode using Oracle 8i so that they could
use a common source. Otherwise they could not get support from Oracle for
any problems on their Japanese system without going through the Tokyo Oracle
office. With the time zone differences and translation problems, some times
simple problems took a long time to fix.
I am starting on another project using ICU http://oss.software.ibm.com/icu.
which I personally like because it has a rich set of globalization features
and it is cross platform. Earlier I implemented an Apache Web server
application for Linux and Solaris using ICU. The price is right - FREE. I
am also planning on contributing my code if my mods are accepted into the
ICU 1.7 base. It provides an alternate API that is easier to use for HTML
scripting languages and improves on the Apache MOD_MIME handing for types
you want MOD_XICU to handle. It also repackages ICU for Apache memory and
resource handling.
The other factor that is confusing is that the traits that make a company
good at localization are almost the opposite traits that a good
globalization company needs. That is why we don't do any localization.
Localizers are great detail people, they take charge, and usually establish
long term relationships. To do a good job globalizers need to look a the
big picture, have you make all critical decisions and leave you caple of
doing the job yourselves. If you don't understand why you made the decision
then they failed. You will always need localizers to do translations, you
want good detail people. Project management is a large part of the job.
Globalization consulting is like management consulting, is is not a cookie
cutter operation. The soultion must be confortable for your individual
company culture or it will not work. It has to come from within. There has
to be buyin and participation or the process fails. This is because
globalization affects the was everyone develops and supports code. It has
to be part of the company not a one time conversion.
What a good globalization consultant will do is the hard part. He or she
will help you with the questions. Without knowing what the questions are
you can not find the answers. They can also provide you with guidance from
their experience as it what works and what does not. For example one area
that is often over looked is fonts. For some projects that can be the
hardest part of the project. There are also some advantages and
disadvantages of using Unicode when it comes to Fonts.
The bottom line is that it used to be leading edge to use Unicode. Now I
feel that if you stay with code page technology they you will be left
behind.
Carl
-----Original Message-----
From: J. P. [mailto:emd0021@yahoo.com]
Sent: Tuesday, October 24, 2000 11:23 AM
To: Unicode List
Subject: Convincing executives of character code perils
Articulating and expressing concerns to company
executives about the perils associated with managing
multiple character sets is DAUNTING task. The company
would like to move ahead regardless, which tells me we
haven't done a good job of educating them.
I'm trying to temper my cry of "WOLF", while trying to
educate executives on the RISKS of introducing a
foreign lanugage other than ENGLISH - French, German,
Spanish.
We're a multiplatform company (IBM mainframe, NT's,
Unix, etc.) with a significant amount of programmed
integration across platforms, managed centrally. Data
exchange and integration is present across all
platforms in many instances and is done both
interactively and in batch or background.
Localization aside, how have you communicated issues
and risks associated with introduction of a Western
European language?
How have you sold your EXECUTIVES on the perils of
this READY-FIRE-AIM mentality?
Signed appropriately so,
Me
__________________________________________________
Do You Yahoo!?
Yahoo! Messenger - Talk while you surf! It's FREE.
http://im.yahoo.com/
This archive was generated by hypermail 2.1.2 : Tue Jul 10 2001 - 17:21:14 EDT