Viv,

The first client has asked for one particular field to be 'translated', another may ask for a second and may or may not want the first.

We are in Canada whereas this particular client is in the USA.
We have 'postal codes' and they have 'zip codes'.
Also, we use 'colour', 'labour', etc and they spell those words 'color' and 'labor'.

I agree that a table approach is better. We can use localized versions and if the phrase is found in the table it will be translated.


>Hi,
>
>>
>According to the docs, a 'H' file is included at compile time, correct?
>>
>Yes.
>
>>
>We really don't want to recompile the application if we decided another phrase to translate.
>A free standing .dbf would not require a recompile - only the distribution of the table.
>>
>So how does the app know that it should use the new table lookup if you don't change the code? Whether you use a table or an include file you still have to make the relevant source code changes.
>
>There are times when a table based approach is better. But if you are making these changes to benefit just one user why inflict the same overhead on all of the other users ?
>
>Regards,
>Viv