Greetings,

As I found out that there is possible bug or conflict in language selection of taxonomies on nodes.


Summary of the problem:


Taxonomies are shown as depend on orginal langauge of node (if it don't have translated version of the node) when it should be another langauge.


Steps


-Create a taxonomy vocabulary with 3 languages with allowed translation.

English | French | Turkish
Hello | Bonjour | Merhaba
House | Maison | Ev

-Create a node type with allowed to translation (Name of the content type: "testing", field name "taxonomy").
-You may translate field's name or other details. (french version "taxonomie", turkish version "taxonomi" ). We choose interface language to display.
-Add a field with term references

-Create a new content, name it "a new content" in Turkish. Lets choose "Merhaba" in "taxonomy" field. Its node number is "5".

-Open this new node example.com/tr/node/5 (default langauge of site is English )
You may see as
taxonomi: Merhaba
-Now use URL as example.com/fr/node/5
you should see
taxonomie: Bonjour
However it appears as
taxonomie: Merhaba
in example.com/node/5, English langauge
taxonomy: Merhaba

If you create translated version of "a new content" as French, example.com/fr/node/5 url will show you as correct one.

taxonomie: Bonjour
But still English would be (example.com/node/5)
taxonomy: Merhaba

The need of the problem is even if user didn't translate the content, taxonomies should appear in correct form, like its field names.

Note: I am not really sure it is a dublicate problem but as I searched in last 2 days, I only found very old examples of problem (exp:
https://www.drupal.org/forum/support/post-installation/2010-03-26/taxono...) and another maybe more up-to-date similar one. (https://www.drupal.org/project/drupal/issues/2930458)

Thanks

CommentFileSizeAuthor
#18 taxonomy-term-translation-on-not-translated-nodes-3071330-18.patch1.43 KBpablo_pukha
#17 Screenshot 2024-06-23 at 11.36.24.jpg19.21 KBmonkk

Issue fork drupal-3071330

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:

About issue forks

Comments

Erso created an issue. See original summary.

Erso’s picture

Erso commented
Issue summary: View changes
avpaderno’s picture

avpaderno
he/him
Primary language Italian
Location Brescia, 🇮🇹 🇪🇺
commented
Version: 8.7.x-dev » 8.8.x-dev
Issue tags: -, -#translation, -#localization, -#international

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

larowlan’s picture

larowlan
Location 🇦🇺🏝.au GMT+10
commented
Priority: Major » Normal
Status: Active » Postponed (maintainer needs more info)
Issue tags: +Bug Smash Initiative

Is each node referring to the same tid?

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

marksmith’s picture

marksmith commented

I can confirm that this is indeed an existing problem in views.

Let's presuppose that the Taxonomy vocabulary is localized, in two languages.

If node content is either (1) not translatable or (2) translatable but not localized (language not specified), taxonomies show up in the localized version, in the language chosen for the interface (e.g. via url). That is the expected behavior.

If node content is both (1) translatable and (2) localized (i.e. content with a specified language), taxonomies will always show up in the language chosen for the localized content (irrespective of the interface language). That is problematic if you do not have a translated version of the node content in the desired language but you do have a translated taxonomy in the desired language.

It would be much more useful when taxonomy language would follow the interface in such situations (like field names, as suggested by the reporter).

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

smustgrave commented
Status: Postponed (maintainer needs more info) » Active
Issue tags: +Needs issue summary update, +Needs steps to reproduce

Based on #11 this could still be an issue. Moving to active and tagging for IS and steps to reproduce

monkk’s picture

monkk commented

I can confirm that D10 as well:
1. I have nodes that are translatable, but not localized
2. I manage language via session
3. Opening node in non-localized language all labels are translated, but taxonomy field itself is not.

avpaderno’s picture

avpaderno
he/him
Primary language Italian
Location Brescia, 🇮🇹 🇪🇺
commented
Title: Taxonomy Term Translation on Not Translated Nodes » Taxonomy term translation on not translated nodes
monkk’s picture

monkk commented
StatusFileSize
new Screenshot 2024-06-23 at 11.36.24.jpg19.21 KB

I attached image to describe issue better:
1. Node is not translatable, but not localized, ie only id default language
2. Reviewing node by forcing language in URL or managing it via session results in same: label translated to target language, but fields with taxonomy reference displayed in default language, but not URL/Session language.

Would be happy to pay for the fix if anyone would be intersted.

pablo_pukha’s picture

pablo_pukha commented
StatusFileSize
new taxonomy-term-translation-on-not-translated-nodes-3071330-18.patch1.43 KB

I have reviewed the issue and worked on a patch.

The patch fixes this by check if formatter is entity reference. While this solution works for the reported issue, I am unsure if it covers all edge cases. Feedback on this would be greatly appreciated.

Please review the patch and let me know if there are any improvements or alternative approaches you’d suggest

thomas.wardin’s picture

thomas.wardin commented

Does exactly what I needed on a D11 site. Did not find any unintended side effects so far.

Thank you, pablo_pukha!

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.

pablo_pukha’s picture

pablo_pukha commented

Pushed an MR with a better approach.

Instead of branching on the formatter type in EntityViewDisplay (which is a layering violation), the fix is in EntityReferenceFormatterBase::getEntitiesToView(): we no longer pass the referring entity's $langcode to EntityRepository::getTranslationFromContext(). Omitting it makes the method fall back to the current content language, which is what we actually want when resolving translations of referenced entities.
Added a test case in EntityReferenceFieldTranslatedReferenceViewTest for a translatable referrer without a translation in the target language.

pablo_pukha’s picture

pablo_pukha commented
Status: Active » Needs review
smustgrave’s picture

smustgrave commented
Status: Needs review » Needs work

Not seeing the MR, but still needs a summary update though please.

pablo_pukha opened merge request !15631