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.
Here is a table of the individual issues that need to be resolved in order to realize the overall plan.
| Problem | Issue(s) | Discussion/explanation | Follow-up |
|---|
[1] Some entities lack data tables[DONE!] | | 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. | |
[2] Join field tables to entity data table[DONE!] | #2218065: Need to join fields to the entity field data tables, not entity tables, or filtering increases number of results | 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. | |
[3] Add entity-level language filters [DONE! Some followups may be needed...] | | 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. | 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 | Note: Depends on [3]
| 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... | | [5] Remove field-level language filters [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 |
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. | 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]. |
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 |
[7] UI: Language choice labels DONE! | #2037979: "Current user's language" views filter label is named very misleading | The language choice called "Current user's language" really means "The negotiated language". This label is confusing and needs an update. | |
| [8] Update help and documentation | | The help and documentation needs to explain this stuff | |
[9] Field-based multilingual views with relationships do not work Fixed as part of a different issue. | #2446681: [PP-1] Error "Column 'langcode' in field list is ambiguous" thrown due to TranslationLanguageRenderer not rendering a field from a relationship | 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. | |
| [10] Views with non-translatable fields seem to be somewhat broken | #2451657: Views should not condition joins on the langcode of fields that are not translatable | 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. | |
[11] Views with bulk operations (admin views) are confusing Done! | | Since views show translations and entity bulk operations operate on the entities as a whole, it could lead to confusion and loss of data | |
| [12] Glossary Ajax doesn't work with multilingual | #2600804: AJAXified glossary view arguments fail when Language URL detection enabled | | |