Re: Internationalization standards

[Al Mac Wheel <macwheel99@xxxxxxxxxx>]

I also looked into this several years ago, when I found out that the 
"Spanish" of a package was European & not South American.

One set of dimensions is how to handle different human languages.
You have to have a substitution system so the people see as much as 
possible in their native language:
* screen field labels
* report headers
* menu options
* sign on screen
* help text
* messages & error messages
* output to other OS ... such as 400 data into an Excel

this applies to artifacts of OS, Aps, using tools

Plan standards for growth, so that as there is programming personnel 
turn-over & visiting consultants, you don't end up with new programs that 
work only in the native language of the programmer.

Then there is the text that humans key in, such as shipping instructions.
If you have a multi-linqual work force, is there practicality of 
translating human input text automatically & it being understandable?

You may have shipments that cross international boundaries & have to have 
text that is intelligible in multiple languages.  Verify it is working.

Al Macintyre

 DeLong, Eric wrote:
> I'm trying to get feedback on standard practices involved in the 
> intranationalization of an app.  This is just curiosity on my part, for 
> now, but I expect there might be a project for this soon.
>
> Here are some of the basic questions I have...
> 1) base field dimensions for currency fields.  What scaling factors to use 
> for aggregation field sizes?
> 2) Character fields should use some flavor of UCS;  assuming that the 
> %UCS2() bif make this flavor easiest to use?
> 3) Wondering about text constants:  If building a new business logic 
> interface that is intended to support web-service/webapp, are MSGF objects 
> still the best way to support language-based resources?
>
> I looked at this several years ago, and have a pretty decent grasp on IBMs 
> recommendations at that time, but I wonder if these techniques are still 
> preferred in light of IBM's modernization roadmap....
>
> Thanks for any insights,
> Eric DeLong
> --