× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Multi Language Support on the AS/400
  • From: FGlenski@xxxxxxx
  • Date: Sat, 28 Jun 1997 13:16:13 -0400 (EDT)

Hi Chuck,
There are many assumptions you need to reconsider when providing multiple
languages on one AS/400.  I will try to list a few of the MAJOR areas to
stimulate your thoughts.  Remember, you have to live with multiple languages,
not just provide them.  

1. Storage - This is usually the first one that comes up.  It is easily
defined and easily solved,  buy more disks!.  IBM sales folk love this. :)  
For each additional language on a CISC (V3R2) machine you will need 150 to
300 Mb.  For each additional language on a RISC (V3R7) machine you will need
 180 to 450 Mb.  The actuall size will vary depending on what licensed
programs you have installed.  The bigger sizes are for double byte languages
like Japanese with lots of LPPs.

2. Data Integrity - This can be a real nasty area and requires knowledge of
code pages, CCSIDs, and character sets.  However, thanks to the AS/400's
internationalization support it is possible to correct this on a system level
without (usually) any significant program code changes.  The details are too
complex for a short email, so I will give just one short example.
Entry of data by non-usa type terminals (5250 or PC emulation) may result in
DIFFERENT hex values for the same displayed character.  Unfortunately, the
current AS/400 defaults on device and file configuration will allow this to
occur.  Basically what happens is the following:
a) USA person types in "50#"  or in hex"F5F07B".  
b) Spanish person displays it and sees "50Ñ" .
c) If the Spanish person "fixes" it  to "50#" then the hex value will become
"F5F069".  and will appear as "50Ñ" on the USA display.  This may cause
problems with SORTs, LOKUPs and other matching type functions.  (note that
the Ñ key does not exist on a US keyboard, you have to type alt+165 on a PC) 

3) CULTURAL differences - This is the most difficult area to correct unless
you have technical staff who have lived and worked in the target culture for
a number of years.   This is difficult because most IS people are completly
unaware of which questions to ask.  For example, have you considered DAILY
inflation currency adjustment?  The peso can move quickly and you could lose
alot of money using last months conversion rates.  Have you considered
simultainious multiple date and time formats?  Depending on the education
level of your users they may be used to entering YMD or DMY or MDY.  This
becomes more important for users of mulitple systems (such as accounts who
use Spanish PC programs and the AS/400) as errors are more likely to occur
when they switch between programs.
Have you considered how complex (dense) to have your screens?  US culture
accepts very dense screens (i.e. multiple row subfiles with 1 character
headings) much more easily than most other cultures.  Your training,
productivity, and error rates may be unacceptable without significant screen
redesign.  One of our clients is looking at 3 to 6 MONTHS for training on the
unconverted screens.  By the way, how many of your trainers speak fluent
Mexican Spanish?

4) LANGUAGE  differences.  This is the most confusing area as interpretations
vary depending on the culture.  For example, Spain Spainsh is not the same as
Mexican Spanish.  Are your Spanish users going to be fluent in English? If
not, how are your operators going to communicate with the Mexican operators
to debug problems at 2:00 am when the batch run fails? (I know, IWNH (it will
never happen! :).  The IBM language support ONLY provides translated system
messages.  Have you considered how to translate your business software?  US
English is the most compressed language I have seen, so translation of
screens, reports, and error messages will require significantly more space.
 This will most likely require significant redesign of most screens and
reports.

5. System Support - A multi-language AS/400 may have to support terminals
which the local system support vendor is not familar with.  Have you
considered how you are going to support and configure the remote devices?
 What if there is a problem with them when you install a new OS/400 release?
 Who will solve it?  Unfortunately, mulitlanguage machine problems usually
require consulting MULITPLE IBM divisions for resolution.   The support line
is usually NOT familar with the type of problem and does NOT speak Mexican
Spanish.  Somone has to do the technical translation.  I would strongly
suggest that you consider having an identical device in your home office for
every device you will have in Mexico.
  
6. 3rd Party Applications - Suitability of any 3rd party application must be
determined by a reviewer who is native to (or very familar with) the culture
the application is intended for.  DO NOT rely on vendor statements.  DO NOT
rely on your own review.  You are culturally biased to US English.  Remember
#2 above, the vendor is most likely not familar with your needs as far as
transferring data between different applications.  Since you mentioned BPCS
in your last email this will apply to you.

For further information I would suggest looking on the COMMON CDROM for
Internationalization presentations from San Francisco (Fall 95) or
Atlanta(Spring 96).  There are a number of IBM and MicroSoft manuals
concerning internationalization (I18N) but they are mostly advanced technical
references aimed at software developers.  IBM will be coming out with a
redbook soon (this year I hope) on I18N called "Speak the Right Language..."
which is the only IBM basic intro. and How-To book I am aware of.  It is not
available yet.  
If you want the list of manuals or further information please contact me at 
FRANK@ja-i18n.com .
  
The above comments are based on my experience as a software
internationalization consultant for an IBM business partner.  Most of our
clients are either software developers who want to sell their software in
another culture or manufacturing and processing companies who want to use
their inhouse systems to support operations in another culture. 

HTH
Frank.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* This is the Midrange System Mailing List!  To submit a new message,   *
* send your mail to "MIDRANGE-L@midrange.com".  To unsubscribe from     *
* this list send email to MAJORDOMO@midrange.com and specify            *
* 'unsubscribe MIDRANGE-L' in the body of your message.  Questions      *
* should be directed to the list owner / operator: david@midrange.com   *
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.