Contrib.social

implode() error when translating views with plural variants

Open on Drupal.org →
Created on 25 August 2022, over 2 years ago

Problem/Motivation

The following error occurs when translating a Search API view containing "plural variants"

The website encountered an unexpected error. Please try again later.
TypeError: implode(): Argument #2 ($array) must be of type ?array, string given in implode() (line 76 of core/modules/config_translation/src/FormElement/PluralVariants.php).

implode('', '1 @cuenta') (Line: 76)
Drupal\config_translation\FormElement\PluralVariants->setConfig(Object, Object, '1 @cuenta', 'display.attachment_1.display_options.fields.nid.fallback_options.format_plural_string') (Line: 89)
Drupal\config_translation\FormElement\ListElement->setConfig(Object, Object, Array, 'display.attachment_1.display_options.fields.nid.fallback_options') (Line: 89)
Drupal\config_translation\FormElement\ListElement->setConfig(Object, Object, Array, 'display.attachment_1.display_options.fields.nid') (Line: 89)
Drupal\config_translation\FormElement\ListElement->setConfig(Object, Object, Array, 'display.attachment_1.display_options.fields') (Line: 89)
Drupal\config_translation\FormElement\ListElement->setConfig(Object, Object, Array, 'display.attachment_1.display_options') (Line: 89)
Drupal\config_translation\FormElement\ListElement->setConfig(Object, Object, Array, 'display.attachment_1') (Line: 89)
Drupal\config_translation\FormElement\ListElement->setConfig(Object, Object, Array, 'display') (Line: 89)
Drupal\config_translation\FormElement\ListElement->setConfig(Object, Object, Array) (Line: 290)
Drupal\tmgmt_config\Plugin\tmgmt\Source\ConfigSource->saveTranslation(Object, 'es') (Line: 874)
Drupal\tmgmt\Entity\JobItem->acceptTranslation() (Line: 362)
Drupal\tmgmt\Form\JobItemForm->save(Array, Object)
call_user_func_array(Array, Array) (Line: 114)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 52)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 592)
Drupal\Core\Form\FormBuilder->processForm('tmgmt_job_item_edit_form', Array, Object) (Line: 320)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 73)
...

Plural variants seem to be associated with numeric fields in a Search API index view. When using the native translate view UI in Drupal, the plural variant appears as two separate fields to translate, a "singular form" and a "first plural form":

But when the same view is translated with Translation Management, it mistakenly attempts to combine both fields together and translate as a single field:

This leads to the above error when attempting to save the translated values in the view's configuration because it is expecting to have an array containing the two translated fields, but instead it is only given a single string.

Steps to reproduce

Using Drupal 9.4.3, Search API 1.23, Search API Solr 4.2.7, and Translation Management 1.14:

  1. Create a content type with a number field (float or integer)
  2. Create a Search API Index view that displays fields. Add the number field (from the Content datasource) to the list of displayed fields.
  3. Go to the native view translation interface for that view. Verify that the view contains a "plural variant" within the set of translatable strings defined within the numeric field. It's usually found by drilling down to [display]->fields->[numeric field name]->options for fallback handler->plural variants (or some path similar to that)
  4. Now go to the Translation Management Sources tab, select the View source, and attempt to translate the view. Note the combined plural variant field and resulting error when accepting/saving the translated strings.

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

🐛 Bug report
Status

Active

Version

1.14

Component

Source: Configuration

Created by

🇺🇸United States RichardDavies Portland, Oregon

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

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • Comment over 1 year ago →
    🇸🇪Sweden edward.peters

    I have exactly the same issue. Did you find a solution?

  • Comment over 1 year ago →
    🇺🇸United States RichardDavies Portland, Oregon

    No, I don't think I did other than to manually translate the view through the native Drupal translation UI.

  • Comment about 1 year ago →
    🇷🇺Russia dm66

    Confirmate. I have this bug too

  • Comment about 1 year ago →
    🇸🇪Sweden edward.peters

    My developer has written a patch that fixes this. I have asked him to share here, and hopefully someone can get it into the next module release.

  • Status changed to Needs review about 1 year ago
  • Open in Jenkins → Open on Drupal.org →
    Core: 9.5.x + Environment: PHP 7.3 & MySQL 8
    last update about 1 year ago
    101 pass, 8 fail
  • Comment about 1 year ago →
    🇮🇳India vinaygawade Sawantwadi, Maharashtra

    Here is the patch against 8.x-1.x branch.

  • Comment about 1 year ago →
    System Message
  • Comment 11 months ago →
    🇺🇸United States davemaxg

    I can confirm that using the View result counter - Global field from views also causes this error. I am using 8.x-1.15.
    The patch does not apply to this version either. I will look into a new patch if I have some time.

  • Comment 12 days ago →
    🇺🇸United States fskreuz

    The patch in #6 tried to split the text at the form level, attempting to follow what config_translation did (albeit very specific to Views config and not using the \Drupal\Component\Gettext\PoItem::DELIMITER that's actually used to join the values).

    But there's another issue: The delimiter separating the strings can also get lost after translation (e.g. Google Translate API via tmgmt_google). So while you can check the source text for \Drupal\Component\Gettext\PoItem::DELIMITER and split it for the source, the translation provider might come back with just one string without the delimiters - not something you can split and map 1:1 with the source with the same amount of textfields/textareas.

    An alternative solution would be to split the source string to an array and translate the singular and plurals independently. However, the job item data's #text property is expected in many places to just be a single string. Switching this to also support an array, or have a different key altogether requires refactoring in many places (many spots in the code specifically look for #text or #file).

    Skipping plural_label fields from translation altogether as a workaround will just produce a value of NULL, which also causes the same error in the same spot.

    The workaround is to translate the config with plurals manually via config_translation.

  • Comment 12 days ago →
    🇺🇸United States fskreuz
contrib.social Blog FAQ Discussions
Production build 0.71.5 2024