I have tried both ways but, for sure, a translation table is definitely the way to go. I use a separate translation table for each data table that has layouts and create a field for each field, then a record for every language I want support.
Every data table has a global field for the language in use which relates to the translation table enabling instant switching if the user alters the language.
I use merge fields to replace field labels on layouts, and the field contents for dialog text, field placeholders, etc.
I have a single global variable for the language which is read on startup and used to populate the global language field of each table via a script trigger when a layout is called. I sometimes create additional translation tables for other elements such as dialog boxes or reports, etc.
Marcus, many thanks for this. That’s pretty much what I was thinking.
The only thing producing less work would be if the client was happy to have the Placeholder text (where fields are still empty) calculated according to the translation table. Or get by with just calculated tooltips.
That would allow me to keep the fixed English labels, which would be so much easier to work with.
In any case, your reply is much appreciated.
When using merge variables on your layout while viewing in layout mode, simply turn on "Sample Data" in your view options to see the actual language instead of variables on your layout.
We have over 5000 phrases per language in our language table and use this technique in all our solutions. You don't need to store global fields in your tables, just load up the phrases into memory upon initial load based on the user's language preferences. This technique also allows users to modify labels, tooltips, placeholder text and custom dialogs without having script or layout access. Load time is seemingly instantaneous over a WAN connection.
Many thanks for this Eric.
Merge variables loaded on startup seem to be the way to go.
Your help appreciated.