Add the translation in the same dropdown entry entity , either by adding an attribute for each translation example NameEn, NameFr .. etc this will require you to have multiple reference selectors on the same page with different attributes and show hide based on the language. Or by adding one extra attribute like ‘languageCode’ or an association to language, In this case you will have to enter all values in Name attribute and assign to a language then in the reference selector’s selectable objects tab , retrieve by MF where ‘languageCode’ = users selected language code or association = users language.
Hope this helps.
I found the answer on the this forum https://forum.mendix.com/link/questions/5419
TL/DR: Use a calculated attribute.
For languages, instead of an attribute with a code, associate your entity with System$Language
Now I’m thinking of a way to parameterize the dropdown datasource to allow non-default languages and even choose one among multiple kinds of translatable values. Also, it would be great to make the solution compatible with Mendix Data Hub.
Some ideas: on the UI form in the context of the entity being edited nest a data view with a non-presistable parameter object, then inside that view nest another data view with the same outer object being edited. This will allow sending both objects to a dropdown datasource microflow (stupid Reference Selector widget only allows editing an association of its immediate parent!). In the non-persistable parameter object we can set the desired language and other parameters for the items to retrieve.
The parameter object is then associated with $currentSession and later retrieved by the calculate microflow.
For Mendix Data Hub we can probably parameterize the retrieved items by sending custom HTTP headers and getting these headers in the calculate microflow. The other problem is I cannot cache the parsed headers in a new non-persistable parameter object because of the error: An action with side effects is not allowed in the microflow.
And besides Data Hub still does not allow custom microflows on the server side so there’s no way to clear the cached parameters at the beginning of each request.