Problem/Motivation

The select element type's #options field does not play well with translations when they contain optgroups and subsequently silently fails to translate some of the options.

Steps to reproduce

Using the following YAML for the webform source :

optgroup_select:
  '#type': select
  '#title': 'Example select with optgroup'
  '#options':
    Fruits:
      - Banana
      - Strawberry
      - Mango
    Vegetables:
      3: Turnip
      4: Eggplant
      5: Carrot

And translating it to this (in french in my case), either on the translation UI or in a config directory:

Fruits:
  - Banane
  - Fraise
  - Mangue
Légumes:
  3: Navet
  4: Aubergine
  5: Carotte

Results in the (master) english version:
English select with a list of vegetables and fruits

And the following french version:
French select with a list of vegetables and fruits

Note that the fruits are successfully translated, but not the vegetables.
I think it may be linked to how fruits is an array while vegetables is an object, because changing the fruits IDs to a text value or other numbers makes them untranslated as well.

Additionally, the translation UI shows the same thing as the above screenshot while the config files contain the correct data.
The translation UI for the select element

I have attached the configuration files below.

Proposed resolution

We should be able to edit the select's #options fields reliably, even if it contain optgroups.

Comments

maxime-adagp created an issue. See original summary.

maxime-adagp’s picture

Issue summary: View changes
avpaderno’s picture

Version: 6.1.3 » 6.1.x-dev
maxime-adagp’s picture

After some investigation, optgroups are not properly taken into account in src/Utility/WebformElementHelper.php, in either merge() or applyTranslation().

In this case, we are iterating over the elements inside #options, and we get the following arrays:

  • Fruits and Vegetables in the "master" version
  • Fruits and Légumes in the "translated" version

This leads the loop to skip the vegetables because the "master" version does not contain the Légumes array.

To solve this, a solution would be to delete the master #options arrays, and simply replace them with the translated #options arrays.

I haven't spent time hacking on this but this is the best solution I can think of. Any thoughts?

maxime-adagp’s picture

Status: Active » Needs review
StatusFileSize
new1.59 KB

Here's a first stab, it does fix the issue on this simple form but it doesn't on a bigger form, I'll explore a bit more.

maxime-adagp’s picture

Status: Needs review » Needs work
maxime-adagp’s picture

StatusFileSize
new2 KB

This should fix the regression

maxime-adagp’s picture

StatusFileSize
new1.66 KB
maxime-adagp’s picture

StatusFileSize
new1.61 KB

Here is a cleaner patch.

maxime-adagp’s picture

Status: Needs work » Needs review
StatusFileSize
new1.97 KB

This seems to fit for my use case. I can't run the tests on my own so I hope they will run now.
The patch does not include tests as I haven't wrapped my head around how this is done (I'm relatively new to Drupal).

Suggestions are welcome!

maxime-adagp’s picture

Component: Translation » Code

I just noticed I mislabeled this issue, sorry for the inconvenience.

jrockowitz’s picture

I was able to replicate the issue, and the patch fixes the problem.

I might try to clean up the duplicate merge logic.

jrockowitz’s picture

Status: Needs review » Reviewed & tested by the community
jrockowitz’s picture

Status: Reviewed & tested by the community » Fixed

  • a674df1b committed on 6.1.x
    Issue #3320160 by maxime-adagp: Unreliable translation on select #...

  • a674df1b committed on 6.x
    Issue #3320160 by maxime-adagp: Unreliable translation on select #...

  • a674df1b committed on 6.2.x
    Issue #3320160 by maxime-adagp: Unreliable translation on select #...

Status: Fixed » Closed (fixed)

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