search

formio / formio.js

JavaScript powered Forms with JSON Form Builder
https://formio.github.io/formio.js
MIT License
1.87k stars 1.06k forks source link

[BUG] Form Builder i18n translations affecting components' labels #3531

Open mm-dsibinski opened 3 years ago

mm-dsibinski commented 3 years ago

Environment

Please provide as many details as you can:

Steps to Reproduce

  1. Define i18n translation for 'pl' language, which translates the word 'Display' to 'Wyświetl'
  2. Render FormBuilder and in options set the language to 'pl' and provide i18n translations JSON created in step 1.
  3. Drag any component (e.g. Text field) onto the form builder. In the component's edit window the first tab (Display) is correctly translated to 'Wyświetl':

image

  1. Change the Label of just-inserted component to "Display". See the issue - label's value is also translated to 'Wyświetl': image

Expected behavior

The component's fields (values, labels etc.) are not translated. Only FormIO builder itself is translated.

Observed behavior

Both Form Builder elements (like tabs) and form components are translated. This is not desired. User entered value 'Display' and FormIO changed it to 'Wyświel'. The meaning of "Display" entered by the user might be totally different.

Example

JSFiddle example: https://jsfiddle.net/dsibinski/bLfnda3y/12/

Is it possible to make Form Builder translations be taken into account only for the builder itself, but not for the components' content? If not, what would be the easiest way to achieve that? The goal would be to somehow override rendering all components labels and tell it to not use translations, but its value directly.

travist commented 3 years ago

Thanks for the bug report. We will reproduce on our end and add this to our developer backlog to get resolved.

wag110894 commented 3 years ago

Hello @mm-dsibinski, we are able to replicate on our side. We have created a ticket: (FJS-1481) and has been added to our backlog. We welcome a pull request. We also have a process to expedite this issue if you are interested.

mm-dsibinski commented 3 years ago

Hi @wag110894 , thanks for answering. I'm happy you reproduce this issue on your end. Few questions:

  1. If it just stays in your backlog, what timeframe do you predict for having it fixed?

  2. Speaking about PR, where would I need to look for?

  3. Isn't there any possibility to achieve that with a custom extension? Like custom renderer?

travist commented 3 years ago
  1. This item has not been deemed as critical, so it may be at least 3-6 months before resolution. There is a way to expedite if you want to go that route.
  2. The PR would be in the formio/formio.js repo.
  3. Yes, you can fix this with creating custom templates. See https://github.com/formio/formio.js/wiki/Templates-API
mm-dsibinski commented 3 years ago

For now, I partially managed with custom templates. However, custom templates don't allow altering everything as I'd wish.

Please keep this issue on your side and fix it according to a normal dev schedule.

mm-dsibinski commented 1 year ago

hi, any news on this issue after 3 years? 😉

Sidiro23 commented 3 months ago

Thank you for taking the time to report this issue. We have reproduced this behavior and have created a ticket for it. Ticket for internal tracking: FIO-8442

brendanbond commented 3 months ago

Hey @mm-dsibinski thanks for keeping us honest. We're trying to do a better job (with a very small team) of staying on top of these issues from here on out. We've created the ticket, but the truth is it's going to be hard to prioritize any time soon, and PRs for this kind of thing are welcome!

At first glance, it seems to me that this is because the FormBuilder module passes it's options to the "preview" form - this could be for good reason, but there's no reason the i18n options couldn't be prevented from filtering down to the form level. Let us know if you want to try to tackle this yourself, we'd really appreciate it.