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.i think this one of the downsides to using the concept of "translated fields".
if you want a simple listing of node titles linked to the node with translated nodes you simply list nodes of type X and filter on language.
this doesn't work with translated fields as there is only one node for all languages so nothing to filter on.
whatever code is used for the std language switcher block needs to be used in the field handler.
not entirely sure where this fix is best suited; whether in the std Views plugin for the "link to node" option as this is used in many places and would be easier than re-creating all of these as new handlers in this module.
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | i18nviews-translated_links.patch | 3.99 KB | liquidcms |
Comments
Comment #1
liquidcms CreditAttribution: liquidcms commentedhmm.. oddly enough, the Views handler for this: views_handler_field_node in views_handler_field_node.inc does appear to be language aware; but isn't working.
switching to the Views project and will investigate further.
Comment #2
liquidcms CreditAttribution: liquidcms commentedok, so the issue is obvious and not quite sure which project the issue lies.
the handler looks at node_language; but for translatable fields i think the language is always EN.
if the handler used the site language this would work; so possibly best approach is to make a new handler - which i think then adds an additional checkbox to all views for "Link this field to the original piece of content (i18n aware)"?
possibly this is then better suited to the i18nviews module (where i originally posted this).
Comment #3
dawehnerThe site language seems to be not the right language to choose here, as this might differ from the field language as well.
I guess this custom handler could provide a select field, which says: "Which field should be used to detect the link language" or something similar and based on this generate the link.
Comment #4
liquidcms CreditAttribution: liquidcms commentedsince i have created a patch for i18nviews module i am switching project back to this.
my patch:
- REPLACES nid and title field handlers with my handler that DOES use the global (site) language
@dawehner: can you give me an example of what the "field language" is? are you saying you might set the site language to french and have a node (english) with translated fields where 1 field is showing in en, one in spanish and the rest in fr? what would determine the field's language?
Comment #5
liquidcms CreditAttribution: liquidcms commentedand switching...
Comment #6
dawehnerA general what about extending from views_handler_field_node, i would guess you can save a lot of code if you do that.
I probably didn't expressed myself really well. There might be translations of certain fields, which only appears if you access the node under a certain language. So if you just link the node, this information would be helpful, but sure this could be done later.
Comment #7
liquidcms CreditAttribution: liquidcms commentedi thought perhaps just extending existing class rather than alter call to use a modified copy of that class might be better; but i didn't think i could replace the functionality that is already there (??) so i think i would need to simply "extend" it; which i think then would mean i would need a 2nd checkbox to allow linking to translated link rather than replacing the busted one. didn't seem like the correct approach; but i'll take another look; perhaps i can extend the class and still simply override what the existing check box does.