Support for Object-Based Choices in ChoiceValueModel to Handle i18n

[tdechanterac]

Hello.

Currently, the choice editor is configured like this:

builder
  .property('foo')
  .value(
    createChoiceValueModel({
      choices: [
        'red',
        'blue',
        'green'
      ],
      defaultValue: 'blue'
    })
  );

The choices array consists of simple strings, which works well in most cases. However, it becomes problematic when combined with internationalization (i18n).

issue

When using i18n, choices are often defined dynamically, like this:

const operatorOptions = [
    i18n('condition.operator.eq', 'eq'), 
    i18n('condition.operator.neq', 'neq'),
    i18n('condition.operator.lt', 'lt'), 
    i18n('condition.operator.lte', 'lte'),
    i18n('condition.operator.gt', 'gt'), 
    i18n('condition.operator.gte', 'gte'),
    i18n('condition.operator.contains', 'contains'), 
    i18n('condition.operator.notContains', 'notContains'),
    i18n('condition.operator.startsWith', 'startsWith'), 
    i18n('condition.operator.endsWith', 'endsWith')
];

Each option has a localized display value depending on the user's language. However, the issue is that the stored value in the step is the translated label rather than a stable identifier. This means that the value depends on the language of the user who configured it, leading to inconsistencies when different users with different languages interact with the same data.

Feature request

It would be great to allow defining choices as an array of objects with an id and a displayValue, ensuring that the stored data is always the id, while the displayed value can be localized.

For example:

builder
  .property('foo')
  .value(
    createChoiceValueModel({
      choices: [
        { id: 'eq', displayValue: i18n('condition.operator.eq', 'equals') },
        { id: 'neq', displayValue: i18n('condition.operator.neq', 'not equals') },
        { id: 'lt', displayValue: i18n('condition.operator.lt', 'less than') }
      ],
      defaultValue: 'eq'
    })
  );

With this approach:

The stored value remains consistent (id), avoiding issues caused by language changes.
The displayed value can be localized dynamically based on the user's language.
It's definitly not a priority butt would significantly improve handling of choice-based inputs in internationalized applications.

Thanks! 😊

[b4rtaz]

Hello @tdechanterac,

I'll try to deliver some solution in next days.

[b4rtaz]

Hello @tdechanterac,

please check the 0.14.8 version. Also I added examples to this demo. Basically, the idea is very simple: in the definition JSON, you should store the primary language.

'step.chown.property:properties/mode:choice:Read': 'Odczyt',
'step.chown.property:properties/mode:choice:Write': 'Zapis',
'step.chown.property:properties/mode:choice:Execute': 'Wykonanie'

[tdechanterac]

sounds good.
Let me try this out and get back to you.