Allow select values to be defined to allow better i18n?

[bebraw]

I'm currently setting up a little system with i18n and some selects. Here's an example of one:

    companyTemplate: {
        title: 'Company',
        type: 'string',
        enum: [
            'Custom',
            'Koodilehto osk.'
        ]
    }

I also have a onSubmit handler set up for the form. What I want to do is to detect which option is selected and then update the content of my form based on that selection. This is actually the easy part and I have no problem doing it (just need to set Form values at onSubmit literally).

The problem is that I will need to allow the enum values to be translated. Unfortunately it seems the current implementation has fixed select option values to names. This is understandable given there is only enum to use.

In order to allow i18n I would need some way to set the keys explicitly or through some implicit scheme (ie. default to index based value. This can break if ordering changes, though). Maybe the configuration can be extended somehow to support this use case? Ideally I would like to have a map like this somewhere in the definition:

{
    custom: 'Custom',
    koodilehto: 'Koodilehto osk.'
}

Later on I would replace the values with something that gets injected through i18n but you get the idea. I would perform my custom logic based on these values at onSubmit as described above.

[odf]

My approach would be to translate the whole schema before feeding it into the form component. The reason I picked a configuration format that is plain data is the ability to freely manipulate that data, and - at least at first sight - this looks like a perfect use case for that. Do you think that could work for you? If not, let me know where the issues are.

[bebraw]

My approach would be to translate the whole schema before feeding it into the form component. The reason I picked a configuration format that is plain data is the ability to freely manipulate that data, and - at least at first sight - this looks like a perfect use case for that. Do you think that could work for you? If not, let me know where the issues are.

Yeah, this is the plan as it makes perfect sense given how React works.

The problem is that after translation I would end up with the translated value at my onSubmit handler. Ie. in this case the value of companyTemplate would be Custom, Vapaavalintainen or something else depending on the language. Ideally I would just get some easy to map value there (ie. custom).

[odf]

Ah yes! Sorry, I was being a bit slow here. So ideally I imagine you'd want the values specified in the enum property to be language-independent and the extension to specify a mapping that translates these to language-specific strings for display? That would be somewhat analogous to the title property.

[bebraw]

Ah yes! Sorry, I was being a bit slow here. So ideally I imagine you'd want the values specified in the enum property to be language-independent and the extension to specify a mapping that translates these to language-specific strings for display? That would be somewhat analogous to the title property.

Yeah, that's the idea.

[odf]

Okay, that makes sense and should not be too hard to add.