Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
When the user interface language is based on the user, the entity translation based field should be based on the entity's context language. Adding an option for this would allow for the user to update entity translations in their desired language and still have the autocomplete feature lookup the correct language references.
Also, this module is dependent on the i18n_node module.
Comment | File | Size | Author |
---|---|---|---|
#3 | context_language_option-2220563-1.patch | 3.11 KB | jwhitney64 |
Comments
Comment #1
jwhitney64 CreditAttribution: jwhitney64 commentedComment #2
jwhitney64 CreditAttribution: jwhitney64 commentedComment #3
jwhitney64 CreditAttribution: jwhitney64 commentedComment #4
jwhitney64 CreditAttribution: jwhitney64 commentedComment #5
netsensei CreditAttribution: netsensei commentedThanks for the patch! It got me thinking about how the module behaves.
1/
i18n_language_context()
in your patch calls thei18n_node_i18n_context_language
hook implementation. Option 1 (Select only nodes matching the parent\'s language) callsi18n_node_i18n_context_language
directly. So, in a sense, the same functionality is called.2/
I did notice that
hook_i18n_context_language
() is only implemented in i18n_node and i18n_taxonomy. Both hook implementations only return the object language when the active path is either "taxonomy/term" or "node".i18n_language_context()
only gets called ini18n_taxonomy_taxonomy_term_presave
So that would make sense. However, in our case, the code is called within a form building context which can be invoked from other places. So, there's the potential to cause issues here.I think we need to revisit how this should work
-> We should identify the cases that determine the language to filter upon.
-> We should find a way to fetch that language without breaking things.
Comment #6
netsensei CreditAttribution: netsensei commented1/
Okay. I noticed that
i18n_language_context
doesn't work in the first place. The entire class is being called from an AJAX path (entityreference/autocomplete/single/%/%/%)2/
Cases we should cover:
Interface language = IL
Entity language = EL
a/ Adding node, filter on interface language - while IL = EL
b/ Adding node, filter on parent language - while IL = EL
c/ Editing node, filter on interface language - while IL = EL
d/ Editing node, filter on parent language - while IL = EL
e/ Adding node, filter on interface language - while IL =/= EL
f/ Adding node, filter on parent language - while IL =/= EL
g/ Editing node, filter on interface language - while IL =/= EL
h/ Editing node, filter on parent language - while IL =/= EL
i/ Adding node, user selects parent language manually
j/ Editing node, user selects parent language manually
Cases f, h, i and j are the hardest to do.
- Why? Because we need to rely on the language set on the node form. But Entity Reference doesn't pass any language information to the widget handler.
- But can't we just skip those? Not really, because there native content editors don't want the IL to change if they translate or create a node in a foreign language.
I just discovered that i18n tried to solve cases e/h for node_reference in #314721: Node reference: results returned for interface language rather than node language but never got round fixing this entirely. The discussion pretty much died down on which module should handle language arbitration. Leftover code of the patch from that issue, is still there in i18n_node module, however.