The filter named "Current user's language" is very misleading. Those who know the language system in Drupal core would assume this filter will apply the language preference of the user which is not at all the case. What it's really doing is going through language negotiation using the "Content" negotiation settings for the page where the view is displayed. So the language used is not from the user profile but determined dynamically for the page (and may depend on URL components, session values, etc.)
This is especially misleading since now for most entity types, you have a settings page that lets you default new instances of that entity type to a specific language. It has dynamic options like "Site default language", "Current interface language", "Author's preferred language". The author's preferred language actually means the language of the user authoring the entity there, unlike in views, where the user's language may or may not be the user's preferred language.
- Figure out a better label for this, and rename this filter to that.
- Add an option to choose the "UI text" negotiated language, as an alternative to the "Content" negotiated language. This will need a sensible label as well.
- Regularize the machine code strings used to represent these language options in views configs, as well as for the site default language option.
Proposed names: "Selected language for Content' for content, and "Selected language for User interface text' for UI ("Content" and "User interface text" are the 'name' elements of hook_language_type_info() for these two types).
Proposed machine codes: The strings already defined for them in other contexts (language_content, site_default, etc.), with prefixes/suffixes to avoid possible problems in query substitution.
The function for listing languages has also been moved out of views.module and into the base Views plugin class.