Taxonomy term weight is not translatable, meaning you can't order term translations differently

Created on 19 December 2017, about 7 years ago
Updated 12 September 2024, 4 months ago

Problem/Motivation

Taxonomy weight for one language often affects negatively desired order in another language.
To make all languages accessible all the time, we should be able to optionally set the weights per language.
Example:
Taxonomy for plants in English:
Pine Trees
Shrubs

Taxonomy for plants in French:
ร‰pinettes
Arbustes

Lets say we want to put Arbustes with weight -1 for french, if we do this then Shrubs becomes -1 above Pine Trees.

This is alphabetically undesireable , there may be other reasons for setting weights differently per language.

We have provided a patch below with new automated tests that solves this.

The 'weight' property of a taxonomy term is not translatable, so you are unable to order the terms differently in each language. This makes it impossible, for example, to have the terms alphabetically sorted in each language.

If the weight property were translatable then each language could be ordered independently - a big win.

Steps to reproduce

TBD

Proposed resolution

TBD

Merge request link

6371

Remaining tasks

Feedback from MR
Issue summary completion
Change record

User interface changes

NA

API changes

NA

Data model changes

TBD

Release notes snippet

NA

๐Ÿ› Bug report
Status

Needs work

Version

10.3 โœจ

Component
Taxonomy  โ†’

Last updated about 13 hours ago

  • Maintained by
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States @xjm
  • ๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom @catch
Created by

๐Ÿ‡ฌ๐Ÿ‡งUnited Kingdom nicrodgers Monmouthshire, UK

Live updates comments and jobs are added and updated live.
  • Performance

    It affects performance. It is often combined with the Needs profiling tag.

Sign in to follow issues

Merge Requests

Comments & Activities

Not all content is available!

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

  • ๐Ÿ‡บ๐Ÿ‡ธUnited States smustgrave

    Removing the needs tests tag as they appear to have been added.

    Still could use the IS update and change record so leaving the tags for those. Moving to NW for them.

    Not super clear the issue

    In Drupal 10 I added some terms to the tags vocabulary.
    I'm able to have different orders per language.

  • ๐Ÿ‡จ๐Ÿ‡ฆCanada joseph.olstad

    uploading a tests_only patch to prove that the patch 37 is needed.

  • ๐Ÿ‡จ๐Ÿ‡ฆCanada joseph.olstad

    sorry this one is better

    stright up reroll for 10.1.x

  • ๐Ÿ‡จ๐Ÿ‡ฆCanada joseph.olstad

    Is this issue summary clear enough?

    We need now a change record? or can this be skipped because it's 'optional'?

  • Status changed to Needs review 12 months ago
  • ๐Ÿ‡ฎ๐Ÿ‡ณIndia shalini_jha

    I have able to Reproduce the issues in 11.x .
    1) I have added dutch language (nl)
    2) added same taxonomy terms as mentioned in IS.in english
    3) added translation for two taxonomy term.
    4) Changed weight in English and save . it is changing for both language.

    applied this patch #37 , its fixed the issues and weight is changing according to language selected.
    please review and let me know if you need MR for this.

  • Status changed to Needs work 12 months ago
  • The Needs Review Queue Bot โ†’ tested this issue.

    While you are making the above changes, we recommend that you convert this patch to a merge request โ†’ . Merge requests are preferred over patches. Be sure to hide the old patch files as well. (Converting an issue to a merge request without other contributions to the issue will not receive credit.)

  • Status changed to Needs review 12 months ago
  • ๐Ÿ‡จ๐Ÿ‡ฆCanada joseph.olstad

    The patch and the automated tests have been reviewed however the core maintainers will likely have their say.

    Please create a change record.

    Other than the change record, I believe this is ready.

  • Pipeline finished with Failed
    12 months ago
    Total: 183s
    #84329
  • Status changed to Needs work 12 months ago
  • ๐Ÿ‡บ๐Ÿ‡ธUnited States smustgrave

    Added some nitpicky stuff, but the update hook version should be updated.

    Appears to have a phpcs issue.

    Issue summary was missing standard template, got it started but left TBD for sections I can't answer not being familiar with issue.

    Agree on the need for a CR

    Also agree this appears close though!

  • Status changed to Needs review 12 months ago
  • Pipeline finished with Canceled
    12 months ago
    Total: 102s
    #84342
  • Pipeline finished with Failed
    12 months ago
    #84344
  • Status changed to Needs work 12 months ago
  • The Needs Review Queue Bot โ†’ tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

    This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

    Consult the Drupal Contributor Guide โ†’ to find step-by-step guides for working with issues.

  • Status changed to Needs review 12 months ago
  • Pipeline finished with Failed
    12 months ago
    Total: 499s
    #84375
  • Pipeline finished with Success
    12 months ago
    Total: 577s
    #84382
  • Status changed to RTBC 12 months ago
  • ๐Ÿ‡จ๐Ÿ‡ฆCanada joseph.olstad

    Going out on a limb here, saying it's good.

  • Status changed to Needs work 11 months ago
  • ๐Ÿ‡ฆ๐Ÿ‡บAustralia larowlan ๐Ÿ‡ฆ๐Ÿ‡บ๐Ÿ.au GMT+10

    Left some questions/comments on the MR

  • Pipeline finished with Success
    11 months ago
    Total: 1628s
    #87560
  • Pipeline finished with Success
    11 months ago
    Total: 722s
    #87571
  • ๐Ÿ‡จ๐Ÿ‡ฆCanada joseph.olstad

    Head of 11.x/10.2.x is broken right now so we'll have to re-trigger tests once that's fixed. I imagine that'll be fixed soon.
    https://www.drupal.org/node/3060/qa โ†’

  • ๐Ÿ‡จ๐Ÿ‡ฆCanada joseph.olstad

    Looks like performance profiling tests show degraded performance when testing against Postgres 14.1 . Funny that the other DB systems tested do not have any performance regression.

        There were 3 failures:
        
        1)
        Drupal\Tests\standard\FunctionalJavascript\StandardPerformanceTest::testAnonymous
        Failed asserting that 67 is identical to 66.
        
        /builds/issue/drupal-2931680/vendor/phpunit/phpunit/src/Framework/Constraint/Constraint.php:121
        /builds/issue/drupal-2931680/vendor/phpunit/phpunit/src/Framework/Constraint/IsIdentical.php:79
        /builds/issue/drupal-2931680/core/profiles/standard/tests/src/FunctionalJavascript/StandardPerformanceTest.php:58
        /builds/issue/drupal-2931680/vendor/phpunit/phpunit/src/Framework/TestResult.php:728
        
        2)
        Drupal\Tests\standard\FunctionalJavascript\StandardPerformanceTest::testLogin
        Failed asserting that 41 is identical to 38.
        
        /builds/issue/drupal-2931680/vendor/phpunit/phpunit/src/Framework/Constraint/Constraint.php:121
        /builds/issue/drupal-2931680/vendor/phpunit/phpunit/src/Framework/Constraint/IsIdentical.php:79
        /builds/issue/drupal-2931680/core/profiles/standard/tests/src/FunctionalJavascript/StandardPerformanceTest.php:108
        /builds/issue/drupal-2931680/vendor/phpunit/phpunit/src/Framework/TestResult.php:728
        
        3)
        Drupal\Tests\standard\FunctionalJavascript\StandardPerformanceTest::testLoginBlock
        Failed asserting that 50 is identical to 47.
        
        /builds/issue/drupal-2931680/vendor/phpunit/phpunit/src/Framework/Constraint/Constraint.php:121
        /builds/issue/drupal-2931680/vendor/phpunit/phpunit/src/Framework/Constraint/IsIdentical.php:79
        /builds/issue/drupal-2931680/core/profiles/standard/tests/src/FunctionalJavascript/StandardPerformanceTest.php:138
        /builds/issue/drupal-2931680/vendor/phpunit/phpunit/src/Framework/TestResult.php:728
        
        FAILURES!
        Tests: 3, Assertions: 13, Failures: 3.
    
  • ๐Ÿ‡ณ๐Ÿ‡ดNorway steinmb
  • ๐Ÿ‡ง๐Ÿ‡ชBelgium kriboogh

    Applies to 10.3 and added patch of MR for composer use.

  • ๐Ÿ‡จ๐Ÿ‡ณChina jessey
  • ๐Ÿ‡ณ๐Ÿ‡ดNorway steinmb

    Moving back to 11.x as we are addressing this in HEAD. As we are looking into this on sprint in Barcelona

  • ๐Ÿ‡ณ๐Ÿ‡ดNorway steinmb

    After digging into this, I do not think we can fix it during the sprint, however there is a few things that worry me here:

    It the assumed performance regression test fail we are seeing coming from taxonomy_term_data table and is now in the taxonomy_term_field_data table?
    If I am reading this right, we dictate that ->setTranslatable(TRUE). Do we want to do that? Should this not be an option, most people might not want/need this behaviour?

  • ๐Ÿ‡ฌ๐Ÿ‡ทGreece vensires

    You are correct @steinmb! These kind of things are not reversible - from what I know at least. Since this is a property in that entity's table and not a field, you can't optionally update its schema and set it as translatable or not according to the administrator's choices - at least it doesn't seem correct to do that in any other place than a hook_update_N() or hook_post_update_NAME() implementation.

    I wonder whether something like views_term_hierarchy_weight_field โ†’ 's approach is closer to what we need.

Production build 0.71.5 2024