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

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.

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

sorry this one is better

stright up reroll for 10.1.x

Is this issue summary clear enough?

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

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.

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.)

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.

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!

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.

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

Left some questions/comments on the MR

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 →

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.

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

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

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?

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.

Changing back to a bug as per #28

TODO steps as per #61