I have described elsewhere what I have found to be the best method - for me - of designing for language:
More recently I have realised that this approach offers a couple of further benefits beyond language localisation: the first fairly obvious, the second less so.
Since all the language in the solution is stored in the language table, with one record per item, ready to be republished to the global variables used in the Ui and since this language table has a nice Ui itself it is the work of a moment to open the language editor, find whatever Ui language one wants to change, perhaps contextual help, a field label or a language element used in a report, edit it and click the share button to republish it - done! So fine tuning the language used in the App is extremely easy and this saves lots of time as well as making it easier to raise the quality of the App itself.
The second less obvious benefit is that this method of storing and republishing strings of text to global variables can equally be used for other global variables besides language, it can also be used for settings and for user editable expressions.
So where I used to have a settings table where an admin could adjust all those items which make the system run the way they want, I realised recently that I could instead store those settings in the language table. The advantage is that one can store a limitless number of settings this way with absolutely zero overhead, the cost is that the admin needs to know what language item to look for, but as this avoids having to build any Ui for such items its a winner with me.
For example, our Token Control system offers the admin two adjustments, one to tune the response rate of the Dequeuing Delay and the other to impose a ceiling on the Dequeuing Delay, so I just added $$DQTune and $$DQLimit into the relevant custom function and added the same terms as new language records, the screen shot shows how this appears in practice.
Going beyond this - there is a further refinement that seems to work although I am currently not sure whether there are some potential limitations, this is storing an entire expression in a language record, publishing it to a global variable and then evaluating the global variable to obtain the result of the expression. In the past I have always included a table of admin editable evaluated calculations to position the business logic of the customer within the customer data as opposed to being wrapped up in the definition of the database. Having established that I could instead place these calculable expressions in the language table and have them work as normal was really great, but it is early days with this technique and I am not sure at present how far this can go, maybe I will add a note to this thread at a later date.
So, what variations on these techniques are you using? I shall be very interested to hear and share!