Multiple languages in Powerhouse apps.

[Ian Wedge]

We have used this method, where the labels are held on file keyed by program
ID and language. The language code is set when the operator logs on.

I can't say that there is any noticeable overhead at run-time. It can be
quite a major operation if you are converting to this method, but the bulk
of the system that uses this technique was written this way to start with,
so no problems there.

Although this appears to be designed for using different languages it does
have other benefits. Because we also distribute the maintenance programs for
these labels it has the added advantage of allowing customers to locally
tailor the wording on their screens.

Ian Wedge
Ramesys (Professional Services) Ltd
E-Mail : Ian.Wedge@ramesys.com
Tel    : (01788) 822133
Fax    : (01788) 824144

>
> One option is to store all our hard-coded strings in database tables, then
> retrieve and display them at run-time.  They would be keyed by language
> which could be set by an environment variable (aka logical or
> symbol).  This
> adds some overhead at run time.  Also it requires a lot of
> changes to source
> code, where field labels must be replaced by display fields for new temps
> that hold the field label.  Some strings cannot be handled this way, for
> example, the HELP text on designer procedure statements.
>

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
This list is closed, thus to post to the list, you must be a subscriber.