Hi, just checking out this module. I'm testing this on a single language non-english website and when enabling the examples, the forms that come with the examples module are not editable. The same goes for a form we exported as a feature on an english dev/test site and then enabled this feature on our non-english site. We always get the message: This form has translations and its elements and properties can not be changed.

Creating a form from scratch works on the non-english site. The form elements remain editable.

What's the reason behind this behaviour? Or is this a bug that is being or going to be addressed? It's a major issue for us at the moment and stops us from using this otherwise excellent module.

Comments

kriboogh created an issue. See original summary.

jrockowitz’s picture

Component: Documentation » Code
Assigned: Unassigned » jrockowitz
Category: Support request » Bug report

The error you are seeing is related to the fact that once a YAML is translated the configuration has to be essentially locked to prevent out-of-sync elements across multiple translations.

Still, I think what you have found is a bug that is preventing the English version from being altered even when there are no translations.

I will look into replicating and fixing the problem.

jrockowitz’s picture

Priority: Normal » Major

Changing to Major because this is a showstopping ticket.

jrockowitz’s picture

Status: Active » Needs review
FileSize
46.87 KB

I am not 100% sure what the best approach is to resolving this problem.

The problem is that the exported yamlform and yamlform_option config is for English (ie langcode: en) when the YAML form module is installed on site with a different language, a second language copy of each yamlform and yamlform_option config is created and this is causing the locking.

It seems that if I omit the langcode from all yamlform config file, when the YAML form module is installed the config files are automatically associated with the site default language, this might be okay.

Attached is a patch that removes the 'langcode: en' from all config and allows the YAML form module to work on translated Drupal site.

I am doubtful that this is the right approach. I am going to need to some help resolving this issue. We might have to rethink how the YAML form module is handling translations.

screon’s picture

I have a question about your first comment, jrockowitz. You state that:

The error you are seeing is related to the fact that once a YAML is translated the configuration has to be essentially locked to prevent out-of-sync elements across multiple translations.

Is this a temporary solution or will the translation functionality remain this way?

Because I can image a content editor creating a very long form, translating it into 4 languages and maybe a week later he notices an error in one of the elements or needs to add a new element. That means he would either have to start all over or first remove all translations?

Do you have an idea how to counter this?

jrockowitz’s picture

@screon I don't have an immediate solution because what happens if a site editor alters the English (aka Primary) form, deletes an element, and forgets to update the other 4 translations, not the submitted data for the translations is out of sync.

BTW, a developer could easily work-around the "locking" this by altering a YAML Form's exported configuration for all translations and reimporting it.

The YAML Form module might have provide a custom mechanism to translate just a form's labels and text and not the entire render array.

For example, I could see creating a YAML file for each translation that is just a flattened array of a form's element #title and #descriptions and it could something like...

name:
  '#title': 'Your Name'
email:
  '#title': 'Your Email'
subject:
  '#title': Subject
message:
  '#title': Message

...this information would be overlayed over the primary form.

screon’s picture

Thats seams an interesting approach I guess since you'll always be able to edit the form, indepedent of the translation.

grahl’s picture

That would indeed be a much better solution compared to the current state but please note that field labels are often not the only thing requiring a translation. For example, a translators often also needs to:

  • Translate prefixes & suffixes
  • Translate select/radio/checkbox labels (but not the keys)
  • Translate help text or placeholders in fields
jrockowitz’s picture

So far I think only the below properties need to be translated.

  • #title
  • #description
  • #prefix
  • #suffix
  • #field_prefix
  • #field_suffix
  • #options
  • #questions
  • #answers
  • #placeholder
  • #markup
  • #require_error
  • #admin_title

A few more thoughts...

  • Any existing YAML Form configuration translations can be converted to this new format.
  • The order of the elements can be controlled by the source translation.
  • Right be before a YAML Form's elements are initialized they should be translated.
  • Would be nice to tell translators which element properties are missing translations.
  • Custom properties can be added manually to the translation.
jrockowitz’s picture

Hopefully we can also get YAML Forms to be translated via modules like Translation Management Tool.

jrockowitz’s picture

Priority: Major » Critical
Status: Needs review » Needs work
jrockowitz’s picture

Status: Needs work » Active

Tasks

  • Create dedicated yamform translate test form. Include custom elements and place holders
  • Define properties that are translatable. getTranslatableProperties($element)
  • Update translation form to display only element labels.
  • Update yamlform initialization logic to apply labels
  • Write update hook that convert existing translated forms to use new labeling format.
  • Remove locking code and validation handlers.
stevenx’s picture

Need that too, thanks for this awesome module!

jrockowitz’s picture

Status: Active » Fixed

This issue has been fixed via #2825410: Allow forms labels to be translatable.

Please download or checkout the latest dev release.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.