Multi-lingual message files was Re: Spanish characters in Cobol-how to?

On Wed, 09 Aug 2006 18:32:33 GMT, "James J. Gavan"
<jgavandeletethis@shaw.ca> wrote:

>Donald Tees wrote: 
>
>I can't disagree with the concept of separate error message files - and
>OO-wise M/F uses an error class with messages. However I am sympathetic
>to the concerns Doc raised.
>
>Given that a (large) installation does have an error message file then
>it is an absolute MUST that it is tightly controlled, somebody
>performing the control function just like the DBA controls the DB. If
>not, then it is likely say over a period of ten years that 30% of the
>contained messages maybe redundant, having been replaced by new messages
>or new programs. (I doubt I'm illustrating an hypothetical).
>
>The message file is one thing "RW" got right :-). I use Level 88's to
>control messages in one class, then invoke method "errorMessages" to get
>the appropriate literal, (one reason why the retained Working-Storage
>Section in M/F methods is useful). Then I mused if I wanted to have my
>English messages in French or German, I could use a switch at
>application start to invoke methods "EnglishMessages", "FrenchMessages"
>or "GermanMessasges". RW picked up on this immediately saying I should
>be using a message file. But my concern is control of that file, which
>could grow like Topsy.

Be aware that many languages are more verbose than English and the
message sizes should take that into account.  Of course if your
message file is multi-lingual all the reports and screens should be.
This can get interesting and the design even more interesting if
things like currency display, plain number display and date formatting
are language and culture sensitive.
>
>Naturally to get the correct literals for French or German, it would be
>a disaster to use Babelfish :-). You require a particular language
>technician to get those right, possibly some service from the UN or EU.
>
>Bear in mind my methods "messages", while part of the particular class
>are only memory-resident when invoked. Plus, as I code I can enter :-
>
>if this is wrong
>    set ErrorClientNumber to true
>
>without interrupting my train of thought. Subsequently I can do a quick
>search of "set Error", adding the Level 88 names and then finish off by
>taking that complete Error Code List and building the method
>"errorMessages".
>
>If I add to the "EnglishMessages" then of course I have to discipline
>myself to add to the "FrenchMessasges" and "GermanMessages".
>
>An ErrorMessaageFile is the generally accepted way to go. However, which
>approach are you most comfortable with. One other factor - messages I
>have for the Program/Class EditCustomersNames are likely unique to that
>one Program/Class.
>
>Jimmy

On Thu, 10 Aug 2006 00:19:32 GMT, Clark F Morris
<cfmpublic@ns.sympatico.ca> wrote:

>Be aware that many languages are more verbose than English and the
>message sizes should take that into account.  Of course if your
>message file is multi-lingual all the reports and screens should be.
>This can get interesting and the design even more interesting if
>things like currency display, plain number display and date formatting
>are language and culture sensitive.

That can't be.   I've seen the universal translator being used in Star
Trek, and the lip syncing is perfect.

Posted Via mcse.ms Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.mcse.ms