Translation

1) Use translation manager / visual translator (how much is that these days, anyway?)

I might avoid this one.

2) Read strings from the Db (with a language keyfield)

3) have all strings in a class file, and override the properties in

that class file for each language

In your case, where Maia does all the work, you can just generate multi-lingual classes or some such.

4) If you're in the GUI for .NET world, you can look into .resx files for this.

Part of the question around this is who is doing the translations? If it's done before users see the app, then either approach works. If the users are part of the translation effort, then the DB is probably the way to approach this.

-- peter

I haven't thought about translation in a while, but your having asked the question makes me realize that in an OERA world, none of the application needs translation except the UI.  If the interactive UI is .NET, then one should probably be looking for a .NET solution, not an ABL solution.  Likewise, if one is using a third party reporting tool, one would solve that part of the problem in the way appropriate to the tool.  The last thing I would want to do these days is to combine translation data with the business data and have the translation strings floating up and down through all the layers.  Stick it as close to the user as possible.

an error may be generated at one of the lower errors

"Cannot update record foo".

One would assume that this would be an error code (ErrUpdateFoo or

Errno1234) which does get passed back up through the layers. At some

point, you need to convert this error code into a meaningful message.

How would you go about finding the appropriate message for this error

code and providing translation capabilities for this ?

On 23 June 2011 17:41, Thomas Mercer-Hursh

You are such a smart guy

Maia could generate a "language" class for each language of a

generated class . This language file could be swapped in and out with

a "language changed" event . Hmm.

If you have logging capabilities on the server, you will need some language capabilities there too, so this isn't a purely-UI-centric problem.

-- peter

Message was edited by: Peter Judge. Removed some duplicate stuff

How does Progress handle given language appropriate errors?  By passing the number and looking up the message at the UI.  Exactly.

And, what you do for DB logging is completely uncoupled with the UI.  Perhaps it is in one language ... would your really want a DB log that was mixed?  But, in any case it is just the same kind of lookup.  PROMSGS isn't in the DB.

Don't you just love the "double negative" of that language ?

"nie daar nie" (not there not)

This is also the language that calls a Lemon "suurlemoen" (sour lemon)

and and orange "lemoen" (Lemon) ... but "Orange" (the colour) is

"Oranje" ...