Example: Entity FOOD_INGREDIENT with 2 attributes (Id, Name, Description).
Now I need to add the possibility for people to insert names and descriptions in several languages (Portuguese, English, French), so with today's Service Studio there are a couple of choices to allow the users to do this:
1º method: Add more attributes to the entity (Id, NamePT, NameEN, NameFR, DescriptionPT, DescriptionEN, DescriptionFR) and the user can fill each one, on the edit screen. This one is the simplest, but less scalable;
2º method: Add a second entity to hold the translations and JOIN them each time you present the information on the screen. This one requires more coding but it is scalable. You create a second entity:
Then you would modify the first entity to be:
So, these are typically our 2 scenarios for translating data. My idea is a functionality that would allow scalability, but keeping the "simple" part of the first method.
TEXT attributes in entities could have a right-click option saying "Set this attribute as translatable".
Let's imagine that I defined 2 locales in the Espace (EN-us and FR-fr), plus the default one in PT-pt and I want to turn the "Name" attribute to "translatable". I right-click it, choose the option and after this the platform would perform its magic, creating an expand/collapse structure on that attribute (see attached image). Programmers could drag and drop to screens the "child" attributes as they do a normal attribute (usefull for backend pages where users have to fill in all the data, including the translations) to allow users to insert the translations on the backoffice.
If the programmer wants to show the "Name" attribute based on the chosen locale (usefull for frontend pages) then he drags the "Name" attribute itself, and the platform decides at runtime wich of the child translations will appear based on the selected locale.
Your thoughts on this, please.