Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.In the closed issue "Make nat i18n compatible" I found comment #5 saying:
-----------------
The translation module does neat things now like associating terms as translations when they are created by nodes from one translation set.
So:
N(en) <-> N(fr)
| |
T(nat, en) <-> T(nat, fr)
----------------
I can't reproduce this behaviour.
I'm using a vocabulary with translation option "Per language terms. Different terms will be allowed for each language and they can be translated." and module Internationalization 6.x-1.2.
When I translate a node I obtain a term correctly associated with the language of the translation but it is NOT registered as translation to the corresponding term associated to the original node:
N(en) <-> N(fr)
| |
T(nat, en) T(nat, fr) <---- the terms are not related by translation.
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | nat.module.patch | 1.4 KB | skipyT |
| #11 | nat_i18n_v02.patch | 3.51 KB | kars-t |
| #5 | nat_i18n_v01.patch | 3.99 KB | kars-t |
Comments
Comment #1
R.Hendel commentedThat's true - it is very simple to reproduce (at 6.x-1.1-beta3)
In case of translation there would be only one term-ID, which could be translated
I think NAT needs an option wether NAT should produce new terms for translated nodes or link translated nodes to existing terms.
I don't know which way NAT stores data of connection between node and terms. I think this connection needs one more field to store the language.
Comment #2
ericamp commentedI investigated what's happening in term_data table.
The generated terms are correctly stored with a language and different term-IDs.
What is missing is the term-trid (actually =0) that needs to be equal to one of the two term-IDS in both the record.
In your example:
demo-DE term:
id=6
language = de
trid = 6 (not 0 as now)
demo-EN term:
id=7
language = en
trid = 6 (not 0 as now)
Comment #3
kars-t commentedR.Hendel and me need this for a current project. So I have to make a patch for this.
What I currently think and will try out:
The i18n Module sets a vocabulary to "Term per language" or "translatable". If the vocab is set to "translatable" imho NAT should look up the original translation node. If found get its term and set the same association for the new node.
The NAT GUI should add a line about this behavior to let the user know what happens.
On delete of any translation the term should remain until the last node is deleted.
Remaining question:
Is there any problem having two nodes set to the same term?
Comment #4
ericamp commentedI don't understand what translation mode you are thinking of.
The problem is in translation mode: "Per language terms. Different terms will be allowed for each language and they can be translated."
In this configuration the terms are or, perhaps, could be distinct for each language, so two nodes point to two distinct terms (one translation of another best), not to the same term.
Comment #5
kars-t commentedHere is my patch to NAT.
This is only tested by my SimpleTest and _seems_ to work.
I am not really happy because I hat to rewrite some core functions of NAT.
This is a "proof of concept" handle with care!
_nat_add_terms is now called with a reference to the newly added node.
The data is now builded directly inside of this function.
If the i18ntaxonomy module exists I check if the vocabulary is set up to have only one language or is translatable. If this is true I load the original nodes term and set this in the terms list to be saved. If not a new term is saved as it used to be.
Still we don't know if there are any side effects if two nodes are mapped to the same term. And I currently did not test what happens if there are more than 2 languages active and if you try to save the second translation.
Comment #6
ericamp commentedI tried the patch.
It doesn't resolve the problem of having two terms one translation of the other.
Comment #7
kars-t commented@ericamp
Could you please provide more information what you did try?
This patch needs i18ntaxonomy activated and the vocab set to "term translation".
Currently there might be a problem with the update of a node and its term. Otherwise the patch runs currently fine for us. Documentation and usuability is the main problem.
Comment #8
ericamp commented@Kars-T
I activated Multilanguage with TaxonomyTranslation too by using module Internationalization 6.x-1.2.
I have a vocabulary associated to a NAT content type and it is set to Translation mode: "Per language terms. Different terms will be allowed for each language and they can be translated".
I create a content in language A and NAT creates a term in language A associated to the node.
When I translate the node to language B, NAT creates a term in language B but it is not the translation of the term in language A (they are not in the list of terms translations in the vocabulary)
N(lang A) <-> N(lang B)
| |
T(lang A) T(lang B) <--------- there is no relation between these two terms.
To obtain this relation of translation the terms need to have the same value in the field "trid".
Comment #9
R.Hendel commentedI have tried the patch and it works fine for me:
In case of a vocab with localized terms (terms are common for all languages, but their name and description may be localized) for translated nodes NAT will create no further auto-terms. All translated nodes "share" themself one single auto-term.
Thanks, Kars-T :-)
Comment #10
kars-t commented@ericamp I don't really see a use case for this behavior. You have a seperate term for each language. So you want if you switch language on a terms page to switch over to the term in the other language? This is limited due to taxonomy behavior and how they are translated. This is not a NAT problem. NAT might be able to add a synonym but still I don't see the use case. You can of course find the other term through translation just as your diagram is showing.
Comment #11
kars-t commentedNew patch version. I don't why I had the "bright" idea to patch against the latest release but this is against the latest dev.
I added a prevention if the node is an update from a translationset but not the translation source the NAT term is not updated and set to a different language.
Multiple languages are a real pain in regards of NAT. A term that can be translated is expected to be in systems default language. But you can add a node in german to an english system and maybe translate it later. But this means the source of the translation set is english and the term created is not in the default language which means you just have broken translatability.
To avoid this we have only two choices: Never create NAT nodes in any other language but the default. Or mabye add a NAT term by a node in another language but updates can only happen by a node in the default language.
I don't feel well about all of this and the module is not self documenting or anything like intuitive with this behaviour. Maybe someone else could give some input to this issue?
Comment #12
anantagati commentedComment #13
rjmackay commentedSubscribing
Comment #14
rjmackay commentedSubscribing
Comment #15
skipyT commentedHi,
I made also a patch. It is setting automatically the term's language when the node is created.
I know, that this patch is not complet, because is not handling all the taxonomy translation modes. It is working only when Translation mode is set to Per language terms.
I hope I will have time to modify it for every term translation mode.
Comment #16
typoagrafka commentedSubscribing, although I'm interested in a solution for Drupal 7
Comment #17
knalstaaf commentedThis needs to be addressed to D7 as well by this time (as the use of D6 is rapidly ceasing now).