Updated: Comment #N
Problem/Motivation
This issue is spun off from #2161845-13: Node views (front page, admin) do not use the proper language filter.
It is currently not possible to filter a Node view by language, assuming that you have nodes with translations.
For instance, if I have a node in English, which has been translated into Spanish and French, there is no way to filter the view so that I get just the English, just the French, or just the Spanish translation into the results. I can get all 3 or I can get none, but not just one.
There is currently a filter for Node Revision Language, but this doesn't work. In this scenario, I have created 1 node with 3 translations, and the translation information for the 3 languages is stored as 3 rows in the node_field_data table, all with the same revision ID. Here's a screen shot of the node_field_data table for this scenario, with columns nid, vid (revision ID), type, langcode, default_langcode (TRUE or FALSE for "is this the default language), and title:
There is only 1 row in node_revision, where the revision is marked as having language "en" (which is the default language for this node), so the current filter on Revision language gives you all 3 translations if you filter to language 'en', and zero results if you filter to language 'fr' or 'es'.
As a note, filtering by particular field languages doesn't work either. They have PHP errors/exceptions, because they are expecting a column called "language" instead of "langcode", but this is a separate issue: #2218025: Field language filter/sort/etc. for Views do not work and are not needed. And in any case, filtering the language every single field you added to a view would not be practical. You just need a way to filter the view itself.
Also, the rendering of fields is a problem, but that is also a separate issue: #2217569: Fields row plugin: Translation is non-uniform for base fields, Field UI fields, links; no way to choose "this row's language". And if you are using Entity rendering, the links language is also currently a problem, which is a separate issue as well: #2149649: Entity rendering/theming does not use the active entity language to render links.
Proposed resolution
a) Make it clearer in Views that when you create a Node view, you are really making a view of individual node translations, not individual nodes (at least, that is how it is currently behaving, since it ends up joining to the node_field_data table, and there is one row in there for each translation of each node).
b) Add a filter, most likely turned on by default when you create a Node view in the wizard, that selects the default translation for each node (the one whose node_field_data.langcode matches the node_revision.langcode). [This would make it so that you only get 1 result for each node, which will be the default translation of that node.]
c) Add a filter to Views that will let you filter node translations by language (giving you the usual choices of user language, site default language, and particular languages). So, for instance, you could find all Spanish node translations, or French, or all in the current page language. [Maybe this should be an option in the Wizard, to choose between this filter and the "select the default translation for each node" filter? Or maybe this one should be the default? I'm undecided on that point.]
d) Make it clearer in the UI that if you use the "Node Revision: Language" filter, you are filtering for nodes whose default language is the chosen language (that is what the node revision: language filter currently is effectively selecting for). [Probably rename this as "Node Revision: Default language"?]
Remaining tasks
Commit.
User interface changes
Views will work more like what you'd expect, and you'll be able to filter by language of translations or original language as you wish. The label of the existing language filter is renamed 'Original language' and a new one is added labeled 'Translation language'.
API changes
None.
Comment | File | Size | Author |
---|---|---|---|
#21 | interdiff-17-21.txt | 480 bytes | anavarre |
#21 | 2217943-views-node-language-21.patch | 14.64 KB | anavarre |
#17 | 2217943-views-node-language-17.patch | 14.62 KB | Wim Leers |
Comments
Comment #1
Berdirb) Can be done with the default flag, this is easier than a join.
Comment #2
jhodgdonComment #3
jhodgdonAdded link to related issue #2218025: Field language filter/sort/etc. for Views do not work and are not needed (this took me two tries because I forgot the # the first time and I forgot to add a comment the first time too, sorry for the noise).
Comment #4
jhodgdonRE #1 - yes, good idea. That's the db column "default_langcode" in node_field_data, which is TRUE for the row that is the default language translation.
Comment #5
Gábor HojtsyJust reviewed #2301045: Standard profile has views which include elements dependent on uninstalled modules, not valid in config with @webchick and she complained rightly that the existing language filter is bogus on the node admin form. It filters by the original version of the node not the translation language. Without a translation language filter feature, it is not really possible to fix this.
Comment #6
jhodgdonIt seems that several other issues need this to be done.
I just discussed it with Gabor in IRC... some thoughts:
(a) I guess people will understand that they are getting each translation of each node when they see what Views gives them, so we probably do not need to clarify this further.
(c) Adding a filter that lets you actually filter the translations by language is needed by many issues and must be done.
We probably do not need (b) in that case, which would make each node filter to its own default language -- probably the main use case is to show Views in one language only, either that or to (as it is now) show all languages. If we do want to add a filter for (b), we can file a new issue to do that.
(d) is just a label change, so might as well do that too, to avoid confusion.
In the absence of anyone else wanting to do this (it's been sitting for 4 months), I'll take it on.
Comment #7
jhodgdonOK, here's a patch.
I confess: I slipped in one unrelated change in there. I was scanning through the list of Content and Content Revision filters and the one remaining use of "node" jumped out at me (the others have all been changed, except NID, which I didn't mess with, and that one was missed). If that is terrible I can take it out of the patch.
Anyway, here's a patch, with tests and everything. The test passes locally. Let's see if this breaks anything else... but it shouldn't, since it's only adding a new filter to Views.
The filter, sorting, field display, and arguments all work fine, as long as you do not try to display fields (see related issues) other than title, language anyway.
As a note, language sorting is by language code, not by displayed language name, but that is not a function of this patch (exists on other language filters already).
Comment #9
jhodgdonApparently, between when I did a git pull to start working on this, and when I made the patch, FieldConfig became FieldStorage Config... this might fix the broken test, hopefully!
Comment #10
jhodgdonOK, the tests passed this time. Let the reviews begin!
Comment #11
jhodgdonBy the way, I'm unlikely to be back to this before Monday. If someone has a review and someone else besides me wants to revise the patch, I will not be offended in any way -- feel free to reassign, I was just trying to move this forward.
We also do need to fix the "related" issues. Views is really broken for multilingual nodes right now...
Comment #12
Gábor HojtsyGood stuff, looks really good. Thanks for working on this!
Are all the ids unique per table? In other words, could the two language filters peacefully coexist?
In the other issue @plach suggested we call the new one "Translation language". I think this makes sense especially if we call the existing one "Original language" instead.
We use fake language text all the places. IMHO this comment can be removed. We often just reuse the same English text with an appended language code in the test.
Comment #13
jhodgdonOK, I've made some small tweaks here, as suggested in #2/#3.
On #1... I think there is a bit of confusion here. Here's what node module's hook_views_data() is adding for this field/filter/sort (in this new patch I'm about to upload):
The 'id' values here are the string IDs of the handler plugin that is being used for the field, filter, or sort. Those IDs do not have to be unique within the data table -- what has to be unique is the field key, which here is "langcode" in $data['node_field_data']['langcode']. Right?
So I think this is OK? Maybe I didn't understand the comment?
Anyway, here's a new patch.
Comment #14
Gábor HojtsyYeah I thought the 'id's are local identifiers which their name made me think. They are referring to other IDs, thanks for the explanation and examples in IRC. Looks good :) Thanks for working on this :)
Comment #15
jhodgdonFollow-up on the confusion around 'id' in hook_views_data: #2308505: hook_views_data() does not document the very confusingly named 'id' key
Comment #16
jhodgdonComment #17
Wim LeersFixed typo nitpicks.
Comment #18
jhodgdonThanks for the typo nitpick fixes. :)
Comment #19
Dries CreditAttribution: Dries commentedCommitted to 8.x. Thanks!
Comment #21
anavarreThere are still typos here I think. What about this approach which translates 'node' by 'nœud' (which is the recommended french translation for node). Also, it seems we need 'first' and 'second' for french language as well?
Comment #22
anavarreComment #24
anavarrePatch won't apply since it's been committed already. Meh.
Comment #25
anavarreLet's do a follow-up instead, I guess. #2309851: Follow-up for #2217943 fix french language typo
Comment #26
jhodgdonThese are just fake translations for a test. They do not need to be correct French. Gabor: See, that comment was necessary!
Comment #27
Gábor HojtsyComment #29
jhodgdonFollow-up issue #2320521: Follow-up: Node language views filters need label adjustments needs a review...
Comment #30
mahpari CreditAttribution: mahpari commentedHi Guys,
In my website, when i filters view with language and for example open website in English language, it is showing articles only if their Original Language is English and if article has been translated from another language to English, it is not being displayed. My drupal version is 8.3.5.
Can someone please help me? It has been days now that I am struggling with this issue. Thanks
MahPari
Comment #31
jhodgdonHi mahpari -- this issue was resolved in Drupal 8.0.x, and is now closed. Please open a new issue to resolve your problem.
Comment #32
mahpari CreditAttribution: mahpari commentedHi Dear Jhodgdon
I have added new ticket, can you please have a look!?
https://www.drupal.org/node/2898889
Thanks
MahPari
Comment #33
jhodgdonHi! I am not currently working on Views or multilingual support in Drupal Core, so hopefully someone else will help resolve it.
Your other issue could receive quicker action if you provided a set of steps that can be taken to reproduce your issue in a minimal way, such as:
1. Install Drupal in English.
2. Turn on the 4 multilingual modules.
3. Add Spanish as a second language.
4. Go to the content translation settings page and make Page content items translatable.
5. Create a Page content item in Spanish. ...