Request for Internationalization (i18n) Support to Facilitate Localization

[JhonRiveroLinktic]

Is your feature request related to a problem? Please describe.

Yes, the current limitation is that form-js does not support internationalization (i18n), making it challenging to localize forms for users in non-English speaking regions. This situation can be frustrating for developers aiming to create multilingual applications that serve a global audience. The lack of i18n support restricts the usability and accessibility of forms created with form-js for users who do not speak English.

Describe the solution you'd like

I propose the addition of internationalization (i18n) support in form-js, which would include:

The ability to translate all user interface texts (field labels, error messages, buttons, etc.) into different languages.
A simple way for developers to add their own language files, making it easy to customize and extend the available translations based on their application's needs.
An option to change the language at runtime, allowing users to select their preferred language, enhancing the user experience and accessibility.
This feature would allow form-js to be more inclusive and accessible to a broader audience, significantly improving the user experience in multilingual settings.

Describe alternatives you've considered

As an alternative, developers could manually override UI texts after the form has been rendered, but this approach is cumbersome and not scalable. It requires additional coding and maintenance effort, especially when dealing with complex forms or multiple languages.

Another alternative is to fork the form-js project and implement i18n support independently. However, this approach would mean diverging from the main project and missing out on future updates and improvements made by the original form-js team.

Additional context

The addition of i18n support would align form-js with other modern web libraries and frameworks that prioritize accessibility and global usability. This feature would not only benefit developers looking to create more accessible and user-friendly applications but also support the global vision of web inclusivity.

[christian-konrad]

Hi @JhonRiveroLinktic , thank you for opening this issue!

We are currently looking into i18n support from a broader lens.
I am curious about your current or targeted setup.

Do you use or plan to use form-js inside of Camunda, or in a custom application?
Do you already use i18n libraries? What library integration would you favor to be supported by form-js?

[Skaiir]

My personal take on this, and thanks for raising this we definitely will be looking into this eventually, but we shouldn't stray for from something that has already been solved and we should simply follow bpmn-js's solution to this.

What this means for this library would be to provide a translation module. Basically, wrap every user-facing string in a translate(string) call. And then allow for language packs to be supplied to form-js, and the currently active language to be configured.

Anything like UX around translation, configuration, ect, should be handled externally, some implementations may want to exclusively have form-js translated in French, it's not up to this library to decide. This is a flexible solution as it allows anybody to write their own language packs, or maybe use existing ones, in the configurations that they like.

We could then provide another repo with community maintained translations, but they most likely would be under no guarantee from us as translation maintenance is a lot of overheads.

If someone would like to dig through bpmn-js and see how translation is implemented, and provide an equivalent implementation here, I would be happy to get it through the review stages. It's easy coding, just kind of tedious and time consuming :)

Some references:
https://github.com/bpmn-io/bpmn-js
https://github.com/bpmn-io/bpmn-js-i18n

[Skaiir]

We are currently looking into i18n support from a broader lens.

I'd like to add that even under that broader lens, we still need to have an extension point within the form-js library to do translations. So I think we can ignore the broader context within the form-js library, I don't see it clashing in any way with how we're going to do translations at the Camunda level.

The moment there will be some interdependency is if we ever do supply maintained language packs.

[JhonRiveroLinktic]

Hey Christian and Skaiir,

Thank you very much for answering me about the i18n function for form-js. I really appreciate the openness to making the library even better for people around the world.

I've only tried form-js for a personal project I'm slowly working on, but it's pretty clear that this library has a lot of potential. Making it easier to change languages would be a huge win, opening it up to many more users and uses.

I'm all for mirroring the bpmn-js translation settings. This type of flexibility is great, especially when the goal is to keep the web diverse and accessible. I would be totally willing to help, but unfortunately I don't have enough time due to work at the moment.

Thank you very much for having responded.

[okaeiz]

Hey there! Any updates on this?
I am using form-js in Camunda Modeler and I need the form elements to be translated and also their direction should be right to left for my users. I have already raised an issue in Camunda platform to consider right-to-left support for Hebrew, Arabic and Persian.
Do I need to raise an issue here about the RTL support? Is it possible to be implemented in a near future?

PS: We're eager to contribute to the string translations.

[Skaiir]

@okaeiz So with regards to the translations, we'd definitely appreciate some help. Although we're not sure yet 100% whether we'd want to maintain them on the bpmn.io end, or on Camunda's end. But this topic is coming up right now so I'll try and coordinate with you.

In any case, you can already look into building translation files if you'd like to manage this entirely for yourself, see the format in https://github.com/bpmn-io/bpmn-js-i18n/blob/main/translations/de.js. We will not deviate from this.

Will update as soon as it makes sense :)