If you create a multi-lingual site, and try to use Views on it, you'll run into various problems.
This meta-issue exists to collect all of the various problems in one place.
Overall Plan
- In the presence of multiple languages, each row in an entity view should represent one translation of one entity item. So each row has an entity ID and a language associated with it, for the base table.
- Any filters/sorts/arguments related to fields on an entity should filter/sort based on the translated field values associated with that language on that entity. In other words, the field tables need to be joined based on language, for translated fields.
- You need to be able to filter the entities in the views rows by language of the translation (should also be a field, sort, and argument). Choices:
- Specific languages (enabled languages on the site, plus "undefined" and "all languages")
- Current language (the language chosen by URL, language switcher, and other negotiation) - Entities should also have a field/filter/sort/argument for Original Language.
- If there are relationships/joins in the view to other entities, their language can be filtered independently. However, they need another language choice, which will filter so that their language matches the language of the base entity table (only applies if the base table is an entity).
- When making Views output for a given entity, the user should be given a choice of languages:
- Specific languages (enabled languages on the site, plus "undefined" and "all languages")
- Current language (the language chosen by URL, language switcher, and other negotiation)
- - Row language (the fields/entities/etc. from each entity will be displayed in the language associated with the translation of that entity in the row)
This choice should be a setting on the Display. Whether the output is fields (Field module fields and entity properties like title), entities, links, or whatever, they should all obey the Display language setting.
Individual issues
Here is a table of the individual issues that need to be resolved in order to realize the overall plan.
[1] [DONE!] Some entities lack data tables
Issue(s)
- #2312153: Refactor block_content entity schema to multilingual
- #1498664: Refactor user entity properties to multilingual
Discussion/explanation
In order for each row in a view to represent a translation, every fieldable, translatable entity needs to have a table with the language field in it, which is the data table. Two Core entities lack this table currently: User and Custom Block.
Follow-up
- Document this for contrib entity developers: #2321381: Document that fieldable translatable entities should use data tables
- Actually #2322097: Enforce data tables for translatable entity types in the SQL entity storage
[2] [DONE!] Join field tables to entity data table
Issue(s)
Discussion/explanation
Currently, the Field module's Views integration is joining field data tables to the entity base table. It needs to join to the entity field data table instead, so that the languages on the fields are connected to the language of the views row. For (rare) entities without data table, join as we are now.
Follow-up
[3] [DONE!] Add entity-level language filters
Some followups may be needed...
Issue(s)
- All entities: #1740492: Implement a default entity views data handler -- the other issues below for specific entities are postponed on this issue
- Node: #2217943: Views cannot be filtered by language of translation; follow-up #2320521: Follow-up: Node language views filters need label adjustments
- Taxonomy: Views are not working at all due to #2252739: Taxonomy field handler fatal error in linking to terms, cannot create taxonomy views with defaults; with the fix to that issue: #2320743: Taxonomy views needs filter/field on original language
- Comment: #2320277: Views comment language field/filter is for original language code, no translation language field/filter
- User: #2323939: Views user language field/filter is for original language code, no translation language field/filter
- (maybe?) Entity-level language filters on joined tables need a new option added to match the language of the base view table, if it is an entity. [needs issue] once all entities actually have filters
Discussion/explanation
If view rows are entity translations, you need to have some way to filter views by language of the translation. Views should also be filterable by original/source language. Need sort, field, and argument for both of these as well. Note that the default Views entity data class proposed in #1740492: Implement a default entity views data handler would take care of this for most entities in a reasonable way.
Follow-up
Views provided by Core need to use these filters:
- #2161845: Node views (front page, admin) do not use the proper language filter
- #2323899: Provided default Node views need language filtering
- These issues cover the default provided Views configuration in Node and Taxonomy modules. The default views provided by User and Comment need to be thought about a bit more, once these entities have the right filters.[needs issues]
Also: #2162051: Decide if views should default to having a language filter.
[4] Deal with missing translations
Issue(s)
Note: Depends on [3]
- Node: #2161853: Add views language filter fallback, if node not in language of filter: show in source, show in X, hide
- [needs issues] for other entities? Or expand the Node issue to encompass others?
Discussion/explanation
If you have filtered a view by entity translation language, and a given entity item doesn't have a translation in that language, should there be a fallback so the entity still appears in the view?
Note: you can accomplish this with a view by Filtering to default language only (to eliminate duplicates) and then change "Rendering Language" to "Interface text language selected for page" to have the nodes show the selected language IF it's available. Found solution in comments of this: https://drupal.stackexchange.com/questions/192782/how-do-i-get-views-con...
Follow-up
[5][ DONE!] Remove field-level language filters
#2218025: Field language filter/sort/etc. for Views do not work and are not needed
Field-level language filters exist now but don't make sense if rows are translations and fields are connected correctly to the rows (picking out translations)
[6] Translate the display properly
Issue(s)
Remaining main issue: #2393339: [META] Make sure Views base fields are using Field API for formatting, and do not lose functionality and related/sub issues (see right column).
This will make sure that all fields can be translated (currently base fields cannot be). The solution is to make the Entity field plugins support base fields, which means that the base fields will be using regular Entity formatters instead of Views-specific formatters, and change the base fields in their Views data classes to use Entity field handlers instead of Views-specific handlers.
Past/closed/duplicate issues on this subject:
- #2006606: Views rendering ignores entity language, eg: Identical nodes rendered in views when nodes have translations
- #2149649: Entity rendering/theming does not use the active entity language to render links
- #2394041: Row language settings from entity views should be on display level for all views
- #2217569: Fields row plugin: Translation is non-uniform for base fields, Field UI fields, links; no way to choose "this row's language"
- #2407801: Views generic field handler does not work with base fields
- #2394883: Language setup for entity and field based rendering in views is independent, confusing UI, lacking test coverage
- #2429447: Use data table as views base table, if available.
Discussion/explanation
When this issue was originally filed, if your Views display used entity view modes, they were displayed using your choice of the row's language, the original language of the entity, or the page language, and this setting was on the Row plugin. Field-based views had a setting for Field Language, which was hidden in the "Advanced" setting on the Display plugin, with options only for static languages (English, French, etc.). And only Field UI fields, not base fields like Title, obeyed the Field Language setting. So... The plan:
(a) Unify the language settings and their options for Field and Entity views [this is done]
(b) Put the settings on the Display (not the Row plugin) [this is done]
(c) Make translation work for Base fields as well as Field UI fields [still to do].
Follow-up
Once this issue is done, we need to do a few final manual tests (and file issues/add test coverage if problems are located):
- Make sure that the display is actually working right for both Entity and Field based views: base fields, Field API fields, entity view modes.
- Test using static language choices, plus "original language of entity" (or whatever that is called in the UI, "row language" (or whatever that is called) and "page language" (negotiated/selected language)
- Test field-based views with relationships, such as Entity Reference fields, Taxonomy fields, and node author, and make sure these are working right with respect to number of rows in the result and display language. All fields from all entities should be displayed in the same language.
- Test links: should be going to the entity consistent with the data display (so if this row is in Spanish the link should go to es/node/1 or whatever). Types of links to test: stand-alone (like the Edit link and View link pseudo-fields), automatic (if you have an entity and you check the box that says "include links" or something like that), on fields like Node title that have their own specific plugins and a "link this back to the node" option, and on short string generic entity fields with "link this back" box checked.
(I did part of this testing on 7 Oct 2015 on #2450195: Original language of entities not accessible in views anymore comments 17 and onwards that day).
Additional related issues, child issues, and follow-ups:
- #2582535: Duplicated rows on admin/content if author is translated
- #2582499: User views - user links are not localized
- #2450195: Original language of entities not accessible in views anymore
- #2450205: Translation settings don't appear for node in standard.
- #2420737: Differences in dynamic language names are confusing in views, content, etc.
- #2508892: "Content language of view row" rendering option does not always ensure row language is present
- #3267500: More link text uses interface language, not content language - despite views setting
[7] [DONE!] UI: Language choice labels
Issue(s)
#2037979: "Current user's language" views filter label is named very misleading
Discussion/explanation
The language choice called "Current user's language" really means "The negotiated language". This label is confusing and needs an update.
Follow-up
[8] Update help and documentation
Issue(s)
- #2317975: Update Views help to explain multilingual (hook_help)
- [needs issue] for drupal.org documentation page?
- #2455105: Need views multilingual topic (API topic)
Discussion/explanation
The help and documentation needs to explain this stuff
Follow-up
[9] Field-based multilingual views with relationships do not work Fixed as part of a different issue
Issue(s)
Discussion/explanation
If you create a field-based multilngual view with relationships, and try to display Field UI fields in the view, you get an SQL exception.
Follow-up
[10] Views with non-translatable fields seem to be somewhat broken
Issue(s)
#2451657: Views should not condition joins on the langcode of fields that are not translatable
Discussion/explanation
If you have a translatable entity with a non-translatable field on it, and use that field in a view, it will try to use a nonexistent langcode database field.
Follow-up
[11] [DONE!] Views with bulk operations (admin views) are confusing
Issue(s)
- #2473989: Lack of dynamic language field / filter makes shipping core views hard to be both compatible with mono and multilingual
- #2484037: Make Views bulk operations entity translation aware
- #2476563: Entity operations links tied to original entity language, ignore everything else
- admin/people - when you make User translatable and add a translation of a user, it then shows up twice on admin/people - handled in #2484037: Make Views bulk operations entity translation aware
- When these issues are handled, we should go back and make sure that admin/node, admin/people, and the block and taxonomy pages all make sense
Discussion/explanation
Since views show translations and entity bulk operations operate on the entities as a whole, it could lead to confusion and loss of data
Follow-up
[12] Glossary Ajax doesn't work with multilingual
Issue(s)
#2600804: AJAXified glossary view arguments fail when Language URL detection enabled
Discussion/explanation
Follow-up
Comment | File | Size | Author |
---|---|---|---|
#69 | Screen Shot 2019-05-14 at 8.02.19 AM.png | 503.25 KB | bkline |
Comments
Comment #1
jhodgdonComment #2
Gábor HojtsyIt is very reasonable to target these for 8.0.x
Comment #3
jhodgdonYeah, definitely 8.0.x -- I meant it to be there, just a finger slip.
Meanwhile: Adding background information that was formerly in the summary of #2218025: Field language filter/sort/etc. for Views do not work and are not needed...
----
There are currently two different types of translatable entities: those with a data table (like Node) nad those without (currently just User and Custom Block).
For entities with a data table, such as nodes:
For entities without a data table, such as User, it's a real mess:
Comment #4
jhodgdonJust had a short discussion with plach and Gábor Hojtsy about what to do if there are joins/relationships in the view.
The problem is this: if you have a view on base table A (an entity), then join to table B (another entity), then there are two entities, each associated with a language, in the view.
So, we need to expand the plan a bit:
a) When rendering a view, render each entity in the language of that entity's value in the row (if it has languages)
b) Each entity gets filtered by language separately
c) We need another choice for entity language filtering, which would be "Match the language of the entity that is the base table for the view"
Added this to the summary.
Comment #5
jhodgdontypo
Comment #6
Gábor HojtsyRescoped #2161845: Node views (front page, admin) do not use the proper language filter to cover the admin view also because it was much easier to cover both at once vs. doing it separately. Also now have a very elaborate test on our expectations of default and specific language behaviors for each. Please review.
Comment #7
jhodgdonSummary updated -- highlighted places where we need more issues to be filed eventually. I'm also going through child issues and updating titles/summaries...
Comment #8
jhodgdonAdd numbers and status
Comment #9
jhodgdonMinor wording adjustment in the master plan, sorry for all the updates, I'm editing issues to make them clearer...
Comment #10
jhodgdonAdded #2317975: Update Views help to explain multilingual to make sure we update the help on this.
Comment #11
jhodgdonRegarding "[3] Add entity-level language filters" from the issue summary... I looked into the existing implementations of hook_views_data() in Core.
Many of them are not entities, or don't have language (like File).
The only ones I think need language filtering are Comment, Node, Taxonomy, and User:
- We took care of Node on #2217943: Views cannot be filtered by language of translation.
- It looks like Comment already has the same filters/fields we added for Node on that issue.
- Taxonomy and User have this too, but they're not wrapped in:
which probably should be added, because it's kind of silly to show/filter/sort by language if there is only one language on your site.
So I tested this. The goal is that for each of these entities, if you make a view of them, there is one row per ID/language, and then you can filter by language. Here's what I found (note: "with language module" means I turned on Language and Content Translation, added a language, made these entities translatable, and translated them; I also had to add a field to User in order to make it translatable):
Comment
No language module
Fine, no language fields/filters/sorts are visible; probably shouldn't be, see above.
With language module
- Initially, View shows all translations of all comments, good!
- I added a language filter. It doesn't work -- it is trying to filter on comment.language but it should be on the field data table (there is no language database column on the comment table).
Filed: #2320277: Views comment language field/filter is for original language code, no translation language field/filter
Taxonomy
No language module
Could not really test. See #2320275: Taxonomy views do not work (fatal error) Will need to revisit once that is fixed.
With language module
Could not really test. See #2320275: Taxonomy views do not work (fatal error) Will need to revisit once that is fixed.
User
Note: probably depends on #1498664: Refactor user entity properties to multilingual being fixed...
No language module
View works. Language displays as English. Shouldn't have the language field/filter/etc. available without Language module, as noted above.
With language module
Rows are just the users, not users + language. Probably should retest once #1498664: Refactor user entity properties to multilingual is fixed.
I've updated the issue summary...
Comment #12
plachThe generalization of node handlers to entities should probably wait for #2319671: ViewsDataController: Step1: Move entity views data into controllers and #1740492: Implement a default entity views data handler.
Comment #13
jhodgdonAgreed on postponing on the entity controllers for Views data.
So, following-up on #11... The Taxonomy error was closed as a duplicate of #2252739: Taxonomy field handler fatal error in linking to terms, cannot create taxonomy views with defaults.
So I tested Taxonomy with the patch for that issue, which works by the way. Everything is cool with Taxonomy in multilingual views: when I translated terms, the view showed all translations of all terms, and I was able to use the language filter and language field with no problems.
So the only thing we should probably fix for taxonomy is the minor issue that it is pretty silly to display the language fields/filters if there is no Language module.
Although I have been thinking about this. I think we should probably still have those filters/fields available (they work OK) -- and we should for Node and Comment as well. The reason is that if someone imports a view from elsewhere and it has those fields, I think you'd end up with some kind of problem.
To test this, I made views of Node and Comment [which both have this if(language is installed) check in their hook_views_data] and then uninstalled the Language and Content Translation modules. I ended up with "Broken/Missing Handler" in the field/filter I had created... The views still mostly worked though -- the filter just wasn't applied, and the field displayed the label only. I guess that's not a tragedy.
So I've added a note to the Comment issue, and filed #2320521: Follow-up: Node language views filters need label adjustments for Node.
Comment #14
Gábor HojtsyThe language field/filter was moved recently to the views module I think in #2301045: Standard profile has views which include elements dependent on uninstalled modules, not valid in config, with the explicit idea that because it is used so widely, it should not be living with language module. Content can have language even without language module, although the language selector UI on content will only be visible once language module is enabled (unless some other module alters it in, which is while possible, not very likely).
Comment #15
jhodgdonFiled #2320743: Taxonomy views needs filter/field on original language for taxonomy (needs to have a filter on Original Language). Summary updated.
Comment #16
Gábor Hojtsy#1498664: Refactor user entity properties to multilingual just landed, so point one all done? :)
Comment #17
Gábor HojtsyOh, well, that has some follow-up tasks to do in the last column, still todo.
Comment #18
jhodgdonI talked to Gábor in IRC just now... I think the bullet point about "enforce that each entity has a data table" can be scrapped. On #2218065: Need to join fields to the entity field data tables, not entity tables, or filtering increases number of results we can fall back to the join we are doing now if an entity doesn't have a data table, and if a contrib entity is multilingual/fieldable without a data table, they will run into this filtering problem... so be it.
But we should document somewhere that a translatable fieldable entity should have a data table. Filed: #2321381: Document that fieldable translatable entities should use data tables
Comment #19
plachComment #20
jhodgdonWow, a lot of progress in the past week! Updated summary.
Comment #21
jhodgdonComment #22
jhodgdonIn item #3 in the issue summary, the follow-up to making sure all entities have the language filters (translation and original) is to survey the provided default views configs and make sure they are appropriately filtered.
I just did a survey, and filed #2323899: Provided default Node views need language filtering to take care of the views provided by Node and Taxonomy, which (aside from the Home view and Node Admin, are lacking filters).
The default Comment view (recent comments block) will also need to be updated -- it has the filter but currently that filter is for the original comment language, not the translation... and there is some question in my mind as to what the correct thing to do for comments is anyway. That probably requires more thought.
I didn't look at the User views either, because we don't have filtering yet there.
Comment #23
jhodgdonTested item #3 in summary for User entities. User views currently only have a filter available for the preferred language of the user, although for users, all translations of all users are now being shown in the results. Filed #2323939: Views user language field/filter is for original language code, no translation language field/filter.
Comment #24
jhodgdonComment #25
jhodgdonComment #26
jhodgdonYippee! All of #3 is done! Updating summary. May need some follow-ups but I'm not sure about that actually.
Comment #27
jhodgdonUpdated #6 to add additional issue link that's blocking progress on this.
Comment #28
jhodgdonUpdated #6 to add another new issue to the fray.
Comment #29
jhodgdonAnother #6 update.
Comment #30
jhodgdonOne more item added to #6, just a note that when all the issues are fixed, to retest and make sure it is all working. I know we have automated tests but... just need to double check it.
Comment #31
jhodgdonUpdating #6 due to one of the issues being resolved! I like it when it gets smaller. :) Actually it's down to 2 open issues now, both of which are being worked on.
Comment #32
jhodgdonUpdating #6 again... progress is being made!
Comment #33
jhodgdonOne more...
Comment #34
jhodgdonUpdating #6 again, to add note about relationships.
Comment #35
jhodgdonUpdating #6 again, with fixed issues! We're getting close...
Comment #36
jhodgdonAdding to sub-meta to this meta.
Comment #37
jhodgdonFound another issue, and updating #6 again.
Comment #38
Gábor HojtsyTwo new issues: #2450205: Translation settings don't appear for node in standard. and #2450195: Original language of entities not accessible in views anymore :/
Comment #39
jhodgdonYeah, I was just going to add that second one to this meta. Didn't know about the first one. Adding both as part of item 6.
Comment #40
jhodgdonJust updating status etc.
Comment #41
jhodgdonRemoving some issues that are part of #2393339: [META] Make sure Views base fields are using Field API for formatting, and do not lose functionality. No real reason to have them on both metas.
Comment #42
jhodgdonSummary update. #9 was fixed.
Comment #43
jhodgdonAdding #2473989: Lack of dynamic language field / filter makes shipping core views hard to be both compatible with mono and multilingual to meta
Comment #44
jhodgdonAdd issue to #11 along with previous issue.
Comment #45
jhodgdonUh oh, I was just testing another issue and noticed that after adding a translation of a User entity, the People page now shows the user twice. We need an issue for this... similar to what is going on for admin/content page currently... which also doesn't seem to be part of this issue.
Adding to summary so it doesn't get forgotten.
Comment #46
plachThat is already being addressed in #2484037: Make Views bulk operations entity translation aware :)
Comment #47
Gábor HojtsyComment #48
Gábor Hojtsy#2504663: Entity operations links tied to original entity language, ignore both views row and UI languages is also a problem :/
Comment #49
jhodgdonAdding that one to the summary. Also combined #11 and #12 in the summary.
Comment #50
dasjoProbably related here, added #2508892: "Content language of view row" rendering option does not always ensure row language is present
Comment #51
jhodgdonOK, adding to summary in #6.
Comment #52
jhodgdon#2504663: Entity operations links tied to original entity language, ignore both views row and UI languages has been marked as dup of #2476563: Entity operations links tied to original entity language, ignore everything else, updating summary and relationships.
Comment #53
jhodgdon#11 has been fixed. Yahoo!
Comment #54
jhodgdonFound a new issue, added to #6.
#2582499: User views - user links are not localized
One step forward, one step back.
Comment #55
jhodgdonFound another one: #2582535: Duplicated rows on admin/content if author is translated -- adding it to [6] because it's related to testing that was listed on [6].
Comment #56
xjm#2600804: AJAXified glossary view arguments fail when Language URL detection enabled might be another issue to add here, although it appears to also exist in D7.
Comment #57
jhodgdonYes, sounds like a good one to add here. Thanks! As a note, many of these issues were also broken in D7. I doubt very many of them are new, really. Anyway, adding to summary and related issues.
Comment #61
_Archy_ CreditAttribution: _Archy_ at PitechPlus commentedI am not quite up to date with this issue, but just found a new one related to this. This might already be in progress / duplicate. Would be nice if someone checked it out: https://www.drupal.org/node/2862511
Comment #62
ajlib CreditAttribution: ajlib commentedAs I was working on major issue triage, I found a multilingual views issue that I linked here as related. I think the issue summary of #2693727 is up-to-date but if someone else could look it over, that would be helpful.
Found here: #2693727: Limiting options for exposed Language filters causes errors and doesn't work for special languages
Comment #66
B-Prod CreditAttribution: B-Prod commentedThere is another use case for which I didn't found any existing issue, but as there are plenty issues regarding Views relationship, I may have missed it.
Hypothesis
Issue
If there is no linked entity through the reference field on the base entity, there are no results at all, because the WHERE clause for the target entity language do not match anything.
Expected result
We should have the base fields displayed.
Reason
The filter on the target entity language is made in a WHERE clause, but it should be possible to make it in the relationship directly (LEFT JOIN ... ON clause).
There is currently no way to do it with Views relationships.
One complex point is to deal with the target entity, which may have some translatable bundles and some other not...
Concrete example
A node that is translatable and have a reference field to a "category" taxonomy term. The category is supposed to be the same for all the node translations, but have to be translatable.
We use here a relationship and not directly the field, in order to add extra fields from the taxonomy entity.
Currently if we do not add a filter on the taxonomy
Is there an existing issue regarding such case, or should I create one?
Comment #67
eahonet CreditAttribution: eahonet commentedComment #68
bklineThe "Moderated content" view doesn't work too well with translated content, either. If you have an English and a Spanish version of a content node with moderated changes in flight for both, only one of them (the most recently saved) will show up in the view.
Comment #69
bklineAm I the only one who finds the table in this issue unreadable? The right sidebar (at least in Chrome) covers the last column of the table and part of the next column to the left. Is it possible to make the table readable? See attached screen shot.
Comment #70
joseph.olstadComment #71
apadernoComment #76
andypostthere's only few issues left
Comment #77
joachim CreditAttribution: joachim as a volunteer commented> In the presence of multiple languages, each row in an entity view should represent one translation of one entity item. So each row has an entity ID and a language associated with it, for the base table.
This doesn't seem right to me. It's not intuitive to how people perceive their content.
On lots of multilingual projects, I've had clients point out that nodes appear multiple times on admin/content when they are translated.
The translation model in D8 is that there is a single node, with multiple translations. So it doesn't make sense to show it multiple times.
Comment #78
dwwI think I just ran into this one on a client project:
The site is multilingual, and the relevant node types are
profile
andblog_entry
, and both bundles can be translated. blog_entry contains an 'author' reference pointing to profile nodes.We've got a view of blog_entry nodes that includes a relationship on an author node. The relationship results in 2 JOINs:
The first is aware that we want to only see records where the langcode matches, but the 2nd JOIN is not. It's only got the
nid
condition for ON. It also needs alangcode
here. I searched the core queue for an open issue about this, and this is the closest I've found. Anyone know of an existing bug report about this? Should I go ahead and create a child issue for it? Seems like a fairly significant bug in how multilingual Views relationships work.Thoughts? Thanks!
Comment #79
dwwAdding #2582535: Duplicated rows on admin/content if author is translated as at least related, not sure if it fits into the "Overall Plan", but that sounds similar to the bug I'm talking about in #78.
Comment #80
DR_jpc CreditAttribution: DR_jpc commentedI hope that my limited understanding of core multilingual setup as of Views will not make my remark unsound.
Multilingual views translation utility (fairly comprehensive as I understand it) does not seem to include a way to handle combine fields exposed filters. When you select the list of fields to be searched in "Choose fields to combine for filtering", it should have a mechanism to combine fields according to the translated language as fields can be set up accordingly.
Example: Spanish language uses fields description_es and location_es for searching a single information value while it should use description_en and location_en when the front-end language is switched to English.
I hope this is the right place for reporting/asking about this. Thanks for your attention
Comment #81
AnybodyAdded #3267500: More link text uses interface language, not content language - despite views setting as the read more text is always output in interface language, see details in that issue. I couldn't find that documented anywhere.
Comment #83
quietone CreditAttribution: quietone at PreviousNext commentedI find the table hard to read so reformatted it.
Comment #84
geek-merlinComment #85
geek-merlinComment #88
BerdirVery old issue with an extremely long issue summary that's apparently almost everything done, especially given that #2473989: Lack of dynamic language field / filter makes shipping core views hard to be both compatible with mono and multilingual just landed.
There's also #3086883: Improve the options in the views language filter and we are experimenting with an idea related to in our project that basically combines the language and default langcode filter in our admin views. The idea is to never have duplicate translations show, if you don't select a language then a default_langcode = 1 condition is added, otherwise the specific language.
That solves for example the problem that searching with default_langcode = 1 is very non-intuitive and only searches in the default translation and not the translation you see. It will also require a dynamic translation renderer, as when you select a language, it should switch from current language translation to row translation.
We'll see if something comes from our experiments that can be in core/contrib, then I'll share it here.