Hi Hilmar
>The text file is read on application startup. This should be relatively fast, and is done only once. Here, I would say a text file can be faster in principle, but I am not sure. Note that you can also use a DBF for easy maintenance, but give the user the final version as a text-file, which you generate.

If you generate the structure of an .ini file, why not generate a define class ... enddefine around it ?
Then you can compile it, and make a createobject() to any language you have defined. Should be a bit faster at start and to switch the language. You loose the ability ***just*** to switch language files in an update, but I am not sure this scenario happens very often.

For designing I am not sure I'ld go the table route here: I think this would be a very nice example for "visual inheritance". Create a base "languagetext" object as custom in a vcx, add a property for each needed entry. Then define each language as a subclass. Benefit: If you have very similar languages (english and american for instance <g>) you can define american as subclass of english and overwrite just the few necesary properties. One of the problems of large .ini-files is missing one or two entries IMHO. This way the entries are always there, albeit in the last language where the property was forgotten to be overwritten. I went this route with strings for a parsing app and was quite happy with "the way". But it was a special case (parsing search engine results) where for instance I had 3 versions of "german" for germany, austria and switzerland, where most of the differences were in URL structure and and special anchors. Having all translations in a table can make searching for missing translations easy - personal preference comes into play here. But for speedy operation go the object route.

my 0.02 EUR

thomas