Problem: Multilingual RPG/DDS - GUI
haze...@conne.net
Hi everybody !
I have a big problem. Our software was developed only for usage with
German language. Only a few programs are for two languages. We did
this by using different screens, e.g. one format for English, the other
for German; or with override using two different display files.
Now we have to make our software multilingual, at least two languages.
There two plans to do this. First plan is to save all constants for
a program in a file for each language and to read the file at the
beginning of the program. If the user is German he gets the German
translation, if he is Dutch he gets the Dutch translation. If there isn't
a Dutch translation the user gets the English translation because English
will be the main language. This plan will take a long time and lots of
work. So we have a second plan. We do not translate our software via RPG
or DDS, we use the translation tables from GUI. For a lot of words that
will do but we have to translate nearly everything, e.g. customer = Kunde
cust.= Kund. / C. = K. / C = K
Does anybody have some experience with these problems or has
anybody already worked with the translating tables GUI ? Or has
anybody a much better idea ?
Please let me know.
Thanx, Ellen
-----------------------------------------------------------------------
Please answer to newsgroup or to haze...@conne.net.
*** This message was written entirely with recycled electrons ***
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Alejandro Martinez Corria
Hi Ellen,
I have been involved in a similar project in the past. The best solution is
to use several MSGF one for each language and to replace only the source
code of the DSPF.
You must replace all lines with fixed literals by output fields with the
keyword
MSGID and a reference to the message containing the literal.
If you have a literal in the middle of a subfile record you must use MSGCON
instead
MSGID.
I wrote a filter program to do that. If your filter is clever enougth, you
can use
allways the same MSGID for equal literals. My suggestion is to make
the reference to the MSGF like *LIBL/MSGFNAME
Afterwards you must recompile the DSPF and the RPG program to avoid
level errors.
My suggestion is to create one language library for each language and to
place
the MSGF there. Before starting the application you must add the language
library to the top of the library list.
If you are interested in any additional explanation you can contact me
off-line.
Alex Martinez Corria.
Steve Hawkins
Alejandro Martinez Corria wrote:
>
> Hi Ellen,
> I have been involved in a similar project in the past. The best solution is
> to use several MSGF one for each language and to replace only the source
> code of the DSPF.
> You must replace all lines with fixed literals by output fields with the
> keyword
> MSGID and a reference to the message containing the literal.
> If you have a literal in the middle of a subfile record you must use MSGCON
> instead
> MSGID.
> I wrote a filter program to do that. If your filter is clever enougth, you
> can use
> allways the same MSGID for equal literals. My suggestion is to make
>
> Alex Martinez Corria.
>
> haze...@conne.net wrote:
>
> > Hi everybody !
> >
> > I have a big problem. Our software was developed only for usage with
> > German language. Only a few programs are for two languages. We did
> > this by using different screens, e.g. one format for English, the other
> > for German; or with override using two different display files.
> > Now we have to make our software multilingual, at least two languages.
> > Does anybody have some experience with these problems or has
> > anybody already worked with the translating tables GUI ? Or has
> > anybody a much better idea ?
> >
> > Please let me know.
> >
> > Thanx, Ellen
> >
> > -----------------------------------------------------------------------
> >
I am designing an approach on multilingual printer files. Same printfile
object but drawing messages from equivlant translated message files in
seperate libraries. Access is controlled by the
library list as the previous post's solution.
IBM's official solution is to have a printer file object in each of
the libraries but I like the other method. We were populating the
text with variables from a COBOL/400 program.
If there is a better method inquiring minds in Illinois would like to
know.
PS: Multilingual design and programming on the AS400 is like a chicken
crossing the road. We need all the help we can get. Outside of
comp.software.international are there newsgroups and or any classes for
the multilingual design on the AS400. I have poured through the
documentation but being old and slow I have to hear the same concepts
again and again until a hole is drilled in my head for them to sink in.
Steve Hawkins
usCA...@ibmmail.com
Mark Phippard
Steve,
Printer files do not support the MSGID keyword in the DDS. They do,
however, support the MSGCON keyword. This allows you to externalize your
text into message files, but it forces you to compile the printer file for
each language.
Our product is designed to be multi-lingual. We did it as follows:
In DSPF objects, the text literals have been converted to output fields
using the MSGID keyword. This message ID says to look in a *MSGF called
"CONSTANTS" for the MSGID. At run time, there is an OVRMSGF command that
overrides to MSGF "ENGLISH", or "FRENCH" or "GERMAN" etc. This is nice
because we only need one display file objects.
For CMD and PRTF objects, the literals can be externalized to message
files, but they are resolved at compile time not run time.
This results in a run-time application architecture as follows:
OBJLIB - Contains all *PGM, display file and other language-neutral
objects.
DTALIB - Contains all database files. (These could be in OBJLIB)
LNGLIB - Contains all CMD and PRTF objects for language. There would be
multiple language libraries.
You can then control the language someone sees just by manipulating the
library list. NOTE: You could locate the "CONSTANTS" MSGF in the language
library and avoid the need for the OVRMSGF command.
If I were to do it again, I would use the MSGCON keyword in the DSPF's
also, and just put those in the LNGLIB with the other language-specific
objects. Why? Run-time performance is effected by having the MSGID
lookups be dynamic. Also, it makes everything consistent.
Also please note that I am totally ignoring DBCS languages, and I am
glossing over the fact that you need to extend the space on screens and
reports that you use for your literals in order to accommodate most of the
non-English languages.
I hope this helps,
Mark Phippard
SoftLanding Systems
Steve Hawkins
Mark;
This is very close to what I envisioned. We planned on a seperate
language library with language specific objects manipulated by
library lists. Thanks for the tips. Much Appreciated.
Steve Hawkins
Mark Phippard wrote:
> Printer files do not support the MSGID keyword in the DDS. They do,
> however, support the MSGCON keyword. This allows you to externalize > your text into message files, but it forces you to compile the printer > file for each language.
>
SNIP
> For CMD and PRTF objects, the literals can be externalized to message
> files, but they are resolved at compile time not run time.
SNIP
> This results in a run-time application architecture as follows:
>
> OBJLIB -
> DTALIB -
> LNGLIB -
>
> You can then control the language someone sees just by manipulating the
> library list.
SNIP
> Mark Phippard
> SoftLanding Systems