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!]
Issue(s)
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
[2] [DONE!]
Issue(s)
>
#2218065: Need to join fields to the entity field data tables, not entity tables, or filtering increases number of results →
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!]
Some followups may be needed...
Issue(s)
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:
Also:
#2162051: Decide if views should default to having a language filter. →
[4] Deal with missing translations
Issue(s)
Note: Depends on [3]
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!]
#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:
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:
[7] [DONE!]
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)
Discussion/explanation
The help and documentation needs to explain this stuff
Follow-up
Fixed as part of a different issue
Issue(s)
🐛
Error "Column 'langcode' in field list is ambiguous" thrown due to TranslationLanguageRenderer not rendering a field from a relationship
Postponed: needs info
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!]
Issue(s)
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