Email handler body translation broken

Created on 9 January 2024, over 1 year ago

Problem/Motivation

When translating a web form with an email handler using a custom body, the translation of the body goes assigned to the "_default" string in user translate interface even if the option of the email body is to use a custom body. This can cause problems if you have multiple webforms translated with custom body because the "_default" string will receive the latest saved webform message and when the translation is updated during a module install or locale-update commands all webforms will get same message as the latest one saved.

Steps to reproduce

You can reproduce it also with the templates provided by default by Webform. Let's take as example "Subscribe" template

You need:
1. Webform latest version
2. A second language so you can translate the webform.

1. Go to User translation interface and search for the string _default -> should be empty or _default
2. Go to Webform Templates -> Click Manage -> Select "Subscribe" webform and go to the email handlers.
3. Change the body to use "Custom body" and add a message "Test message"
4. Translate the template webform and just save the new translation created.
5. Go back to User translation interface and search for string _default -> it contains the text from point 3.

πŸ› Bug report
Status

Active

Version

6.2

Component

Code

Created by

πŸ‡·πŸ‡΄Romania szloredan

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @szloredan
  • πŸ‡ΊπŸ‡ΈUnited States jrockowitz Brooklyn, NY
  • πŸ‡ΊπŸ‡ΈUnited States jrockowitz Brooklyn, NY
  • πŸ‡¨πŸ‡­Switzerland berdir Switzerland

    config/interface translation sync is tricky and there's not too much this module can do about that.

    We were also running into some edge cases with the _default string. I see that there is special logic that only converts it into an html editor if it's not _default or a token, but if it was customized and then you attempt to ange it, the regex will no longer match if it ever has

    or something like that (in our case, it was automatically translated with our TMGMT integration, we should add a check for _default there as well). The client was unable to fix it back then.

  • πŸ‡¨πŸ‡­Switzerland berdir Switzerland

    Maybe \Drupal\webform\Plugin\WebformHandler\EmailWebformHandler::getMessage() could be more lenient with the $is_default_configuration check and run a trim(strip_tags()) on it?

    I also created πŸ› Do not translate special _default key in webform elements Active

Production build 0.71.5 2024