Multi-lingual applications are always a problem (may be less for native
English speakers and companies) but for the rest of the world :).
In my experience there is only a single tool, that retrieves the message
texts at runtime on the fly from message files and that are good old green
screen display files.
Printer files always accepted MSGCON, but retrieved the message texts at
compile time. It was/is always a pain, if a message text needs to be
corrected, i.e. the appropriated printer file(s) need to be recreated.
Everything else, in HTML, XML or whatever, the message text in the
appropriate language must be determined at run time from either a message
file or a database file (or is even worse hard coded within the programs).
We just developed a tool that allows RPG programmers to write web
applications without knowing anything about HTML and JavaScript.
Multilingualism was a big issue, and we had to solve it by determining the
message texts at runtime from the appropriate (overridden) message files
depending on the language.
... the programmer does not need to care about the different languages, he
only specifies the message ids and depending on the user and the associated
language the HTML is prepared and displayed in English, German, French etc.
Mit freundlichen Grüßen / Best regards
Birgitta Hauser
"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"
-----Ursprüngliche Nachricht-----
Von: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] Im Auftrag von John
Yeung
Gesendet: Thursday, 04.9 2014 04:33
An: Midrange Systems Technical Discussion
Betreff: Re: Question for Printer Gurus
On Wed, Sep 3, 2014 at 4:32 PM, Jon Paris <jon.paris@xxxxxxxxxxxxxx> wrote:
I agree that it would be better - as would many, many other options. But
I'm stuck with printer files and nothing else.
I was hoping that more people here had had experience in globalizing their
applications and had some thoughts on how best to handle printer files.
I think what people *with* experience are saying is that the best way to
handle printer files is to do away with them. Birgitta gave a concrete
strategy for using printer files, to which you said
I was rather afraid of that Birgitta, the only other option then seems to
be to take the approach that Booth did and load the fields in the logic, but
that's not a good solution either.
The best available solution isn't always a good solution. In your position,
it seems like "something that works" is better than anything that doesn't
work.
Also, I disagree strongly with this:
I can't believe that printer support is so poor compared with displays -
particularly since green screen are dying - but printer could go on forever.
I mean, I agree with the part about printer support being poor compared with
display support. I disagree that green screens are dying any faster than
printer output. Where I work, print is pretty much dead. There is
definitely no new development in print output, yet there's still a continual
stream of green screen development.
Even where we *need* printed output for whatever reason, there are
replacement options for printer files (DocPath, ACOM, and the like).
With the group of developers we have, it's been easier to learn other forms
of output than other forms of interactive user interface. There has
actually also been more demand from our users for electronic output (usually
Excel) than demand for a different UI (especially from our long-in-the-tooth
users who have gotten freakishly proficient with green screens).
Finally, regardless of how easy or hard it is to learn other UI technologies
and paradigms, in large existing systems, it's easier to replace printer
files one by one in organic fashion than it is to replace a display file
here and a display file there.
John Y.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
