In DATATYPE String field the User needs to put text in multiple language, eventually clicking in a little flag near the input field to switch the languages.
For example, putting the description of a hotel room in a field, he/she needs to put both English and Italian translated text to mantain it separate but in the same field.
In the DATATYPE String field we can obtain the below content:
<?xml version='1.0' encoding='UTF-8'?>
Doppia Exclusive Vista mare Doccia Vasca WC Balcone Aria condizionata
Exclusive Double Sea view WC Air conditioner
This is not supported out-of-the-box, but can be implemented programmatically:
add a TextField and a Button to your editor screen, do not associate TextField with entity attribute
add a ValueChangeListener to the TextField and save the content to the the entity attribute appropriately, depending on what language is currently chosen
using button’s action, choose the language: clear the field and set a flag indicating the language.
Let me know if you need some example code.
BTW why do you want to store both languages in one field? And how are you going to separate them, by XML tags?
Thank you fr your workaround. Unfortunately it is not an acceptable solution for our customer.
To store a text in multiple languages in a single field is a common enterprise need.
If you use muliple fileds for multiple languages in a table, when you add new languages in your web site yu have to change the table structure, and this is not a good solution.
Storing the below in a single field is a good solution:
<?xml version='1.0' encoding='UTF-8'?>
<root available-locales='el_GR,en_GB' default-locale='el_GR'>
<Title language-id='el_GR'>Title in greek</Title>
<Title language-id='en_GB'>Title in english</Title>
</root>
Thank you for the explanation.
We are aware of the problem, there is a related issue. Unfortunately, storing multiple values in one database field is not an ideal solution for us because unlike Liferay a CUBA application is more a “system of records” and usually requires filtering and sorting, which is quite problematic in this case.