Problem/Motivation
Executive summary
There are several language-related fields/filters available for translated entities in Views.
They have somewhat confusing names/descriptions, and the Original Language field does not work.
Details follow.
Original language vs. Translation language
All translatable entities have a field called Original Language, which is [base table].langcode (e.g., node.langcode for Node entities). They also have a field called Translation Language, which is [field data table].langcode (e.g., node_field_data.langcode for Node entities). Also keep in mind that in translatable entity Views currently, each row of the view output is one translation of the entity.
So. Original Language works fine as a filter (or presumably a sort) -- it allows you to filter to nodes (for example) that were originally written in a particular language. So does Translation Language -- it allows you to filter for node translations in a particular language. These are both clear and OK.
However, Original Language doesn't work as a field. The problem is that we are now using Entity field rendering for Views fields (which is generally a good thing, since it allows us to get the right translations and control field access correctly). So although the view thinks it is getting node.langcode as the field (which would give you the original language), when it comes to rendering time what it's really doing is asking the entity for the 'langcode' field. This is giving us node_field_data.langcode instead -- meaning it is always the same output as Translation language.
As far as I know, you cannot access the original language of the node currently via Entity field rendering.
So, the field labeled "Original language" in the UI doesn't work as a Field (though it's fine as a filter/sort).
Other field descriptions
Most/all of the entities have kind of lame descriptions on the language-related fields. This is a more minor problem, but the field labels are misleading or wrong in some cases. Here's a list of ones that should be updated (see comments 17-22):
- All entities: Many of the descriptions say "language code" and none of them should, since what is displayed is not a language code but a language name. So they should all just say "language". (The reason they say "language code" is that the descriptions come from the entity class's baseFieldDefinitions() method and there it is 'langcode' so it is a language code; the entity views data classes need to override these.)
- Taxonomy, Comment, and Custom block: The descriptions for the Translation language field need to be fixed so that they say they are the language of the translation, which they currently do not do.
Proposed resolution
The field description fixes are easy and could/should probably be put into a separate issue.
The problem with the Original Language field could be fixed in two ways:
a) Easy fix - don't expose this field because we cannot actually output it. Just have it as a filter and sort.
b) Complicated fix - figure out how to render this using entity rendering. Probably we would need to add an Original Language field to translatable entities, and then figure out how to tell Views that when rendering node.langcode, it should use that new entity field instead of asking the entity for "langcode".
(b) is the Right Thing to do. It is a D7 regression that we cannot display the original language.
Remaining tasks
Determine if this is still a problem.
Fix. Test.
User interface changes
- Original language field will work.
- Other fields will have better descriptions.
API changes
Shouldn't be.
Data model changes
Probably not, but I'm not sure if we change the entity views data for fields like node.langcode, how much of it gets stored in the View?