Problem/Motivation

FilterPluginBase::groupForm potentially passes already translated values (via configuration translation through t() which can unnecessarily translate said values and insert unneeded strings into locale storage. The code segment below in /core/modules/views/src/Plugin/views/filter/FilterPluginBase.php is causing this issue.

    foreach ($this->options['group_info']['group_items'] as $id => $group) {
      if (!empty($group['title'])) {
        $groups[$id] = $id != 'All' ? $this->t($group['title']) : $group['title'];
      }
    }

Steps to reproduce

  1. Create a view on a multilingual site that has at least one other language enabled
  2. Configuration translation and user interface translation should be enabled
  3. Set up a new view and a page display, add an exposed filter for a field that uses "Grouped filters", add some group items and add labels for them
  4. Access the view page in the non-default language, this will register the group item labels for user interface translation
  5. Translate the view + display via configuration translation and add unique language values for the group labels there
  6. Access the view page in the non-default language again, views will show the group item labels via configuration translation AND register them as new user interface strings to be translated.

Proposed resolution

Rely on configuration translation instead of string translation through t(). We can remove the conditional logic and revise it to:

    foreach ($this->options['group_info']['group_items'] as $id => $group) {
      if (!empty($group['title'])) {
        $groups[$id] = $group['title'];
      }
    }

Issue fork drupal-3284983

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Comments

angrytoast created an issue. See original summary.

lendude’s picture

Status: Active » Reviewed & tested by the community
Issue tags: +Bug Smash Initiative

Easily reproduced with the provided steps.

In light of #2972776: [policy, no patch] Better scoping for bug fix test coverage I'm marking this RTBC without test coverage.

Easy 1 line fix, no new code paths, complex to write tests for with little gain (it would only tests negatives, 'not translated double').

alexpott’s picture

Version: 9.5.x-dev » 9.4.x-dev
Status: Reviewed & tested by the community » Patch (to be ported)

There's probably more of this in views. Nice find!

I agree that testing for the absence of double translation is wrong.

Committed and pushed 80759ce855 to 10.1.x and 23d8da3938 to 10.0.x and 608eabd8e1 to 9.5.x. Thanks!

Will backport to 9.4.x once the branch is unfrozen.

  • alexpott committed 80759ce on 10.1.x
    Issue #3284983 by angrytoast: Views FilterPluginBase::groupForm double...

  • alexpott committed 23d8da3 on 10.0.x
    Issue #3284983 by angrytoast: Views FilterPluginBase::groupForm double...

  • alexpott committed 608eabd on 9.5.x
    Issue #3284983 by angrytoast: Views FilterPluginBase::groupForm double...
alexpott’s picture

Status: Patch (to be ported) » Fixed

Committed 817b40b and pushed to 9.4.x. Thanks!

  • alexpott committed 817b40b on 9.4.x
    Issue #3284983 by angrytoast: Views FilterPluginBase::groupForm double...

Status: Fixed » Closed (fixed)

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