|
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 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.