To create a multilingual value list, one must have a generic multilingual approach. For the sake of simplicity, I will stick to a solution as presented on this site, where text labels are maintained in a specific table with a single repetition field storing the text labels. Each repetition stands for a language.

Table for multilingual texts

In the above-mentioned example, the table with text labels has all languages. When activating a language, all labels of the selected column are loaded into the repetitions of a single global field. This makes the text labels usable anywhere in the solution, without the need to create relationships.

How to create a multilingual value list

Value lists can be created in different ways. To create a multilingual value list, we need to create a single table for each value list. It is straightforward to create a value list based on a certain field. Thus, if you have a table for a specific value list, simply point to a field of any table and you have all values of that field.

In the table for the new value list, you want to have multiple fields. The reason for this is, that you want to be able to refer to a translation. Let’s say you use the solution for multilingual text labels as suggested above, you will display these labels by a reference. All labels of the active language will be stored in the repetitions of a global text field. The table for the labels has a running number in another field, which will not change, whether you delete or skip any number. This means that you have a unique reference to each label, based on that running number. When loading the text labels into a global repetition field, you will use the number field to refer to that number of repetition. Thus, all labels stay fixed on that position and can be referred to easily.

It might look like: L::gT[289], where «L» is the table for all labels, «gT» is the global text field, in which the labels are loaded, and «[289]» is the repetition number you refer to.

The structure of this definition is always the same. It is: Table::Field[repetition number]. Only the repetition number will change, the rest will stay the same for any label. In a multilingual value list, you want to have 1 field for the chosen number, and a text field to build the complete reference. Do not choose a calculation field, but rather a text field with a calculation upon entry.

It might look like this:

The table for the multilingual value list has several fields, among which:

• number field «TranslationID» for the reference
• text field for the translation with calculation «Evaluate ( “Table::GlobalField[” & TranslationID & “]” )» or similar

The text field with the calculation is refreshed when the field TranslationID, on which it is built, is refreshed. If you load, update or change a language, one should make sure that this field «TranslationID» is refreshed in any table used for multilingual value lists.

Refreshing the value list translations

When switching a language, your value lists will not automatically be updated, as these are not calculation fields, but rather ordinary text fields, on which a calculated at data entry is performed. We have to mimic that data entry to update the calculated value.

For this purpose, I use a script, to which I add all the value list tables, in which I will then replace the value in the field “TranslationID” with itself. This will update the language. After this refresh, the multilingual value list will perform effortlessly.

FM Starter and FrankCRM have this included

All the basic ideas for creating a multilingual set-up of your solution are available for free on this website. You will have to build it yourself, though. If you want to accelerate the process, check out FM Starter and FrankCRM, which have these mechanisms already built-in.

In our flagship product FrankCRM, multilingual value lists are used everywhere. The following video shows a few implementations in the user interface. Both the interface and the value lists are multilingual.