Form has translation and its elements and properties can not be changed.

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.

Changing to Major because this is a showstopping ticket.

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.

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?

@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.

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

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

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.

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

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.

Need that too, thanks for this awesome module!

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

Please download or checkout the latest dev release.