RELATED IDEAS
Localised CVL choices
Today, localeString CVLs allow you to select a single or multiple options, and the values are available in all of the defined languages. The option is the same for all languages.
Some markets require different CVL options. For example the months that a snow tyre is suitable for is different in Sweden and New Zealand. This could be a multivalue CVL of all of the months, and the relevant months are selected. In this scenario, the Swedish locale would want January, February, March and New Zealand would want to select July, August and September.
Who would benefit? |
Customers operating globally with products that differentiate by region (climate, culture) |
What impact would it make? |
It would simplify data modeling, user enrichment and publishing of data by locale |
How should it work? |
The "localised" CVL field should present the field data in a way that different options can be selected for different locales. |
Why is it needed? |
Managing this scenario involves customised UI templates, data storage in a complex form (e.g Json) and additional issues such as complexity in Brand Store and syndication. |
Additional feedback, background or context:
-
-
-
-
-
-
-
-
-
- +2
Hello dear team,
Thanks for considering this request, that is still very (very very) expected by Michelin.
As a workaround we indeed had to store this data within json fields, but it makes translations gathering process a nightmare. Let me try to summarize our translation process:
Michelin central marketing/communication team provides Master (english) texts that are imported within PIM
Then countries are asked for translations. But Michelin teams in countries are marketing people, they do not have skills in data and even less in json structure. They are unable to fill json fields. To allow them filling those localized json fields, we have to transform the json field into excel columns for them to fill, then transform those excel columns back into a json message to be imported within PIM, avoiding erasing data for other countries. That makes it very difficult for us to manage and complexifies a LOT our process.
Please let me know if you need more information, we can definitely show you what we currently do, you'll quickly understand why we highly need this enhancement.
Thanks a lot.
Mathilde
Raise the view and make any data type "contextualized", meaning that you can add a context (like market) and have different data for different context.
Today you need a field for each context/market. ItemPublishDateUK, ItemPublishDateDE, ItemPublishDateUS. If context would exist you could configure the Field temPublishDate to have three contexts, UK, DE and US.
The data could be stored as a JSON dictionary
{
"UK":"2024-11-29T10:15:30Z",
"DE":"2024-11-29T11:15:30+01:00",
"US":"2024-11-29T05:15:30-05:00"
}
or like this is the data type is a boolean.
{
"UK": true,
"DE": false,
"US": true
}