Decide if views should default to having a language filter.

This reminds me that long ago, when I used to make views, I would have to add the published == yes filter. That is now a default.

I'm wondering if language filter might be a similar default filter.

There was an irc conversation today where I think @webchick mentioned that @berdir has on occasion mentioned that removing a filter is easier than adding one you didn't know you needed (or dont know how to add).

I don't think having filters automagically added to views on multilingual sites is a good idea: we just need to provide people good examples and they will figure out what they need for their particular use cases. This is why I am suggesting to have an optional translation language filter in the front page view: people can use that one as a very clear example of how to achieve what they need, without requiring us to introduce black magic all around in Views just to support multilingual sites.

IMO we should won't fix this.

Yeah, I'm not sure it's magic, but the proposal is just a filter in views.

In drupal historical fashion we could make a setting for views default so site builders could pick if their views should have a language filter by default or not. (or maybe that would be a contrib module that could do that?)

So... I think there are really two questions here:

a) Should the default views provided by various Drupal Core modules, such as the site home page and some admin screens, default to having a "current language" filter? For this, we've already decided the answer is Yes for the site home page, and I think that the answer is "exposed language filter" for the admin page, right? So I guess there is not just one answer here to the question -- have to think case-by-case.

b) Should the wizard that makes views add a "current language" filter by default? Here, I think the best thing to do would actually be to give the user the choice, on the wizard. They could be presented with all of the language choices they'd get if they added the filter to the view, or they could just have a checkbox to turn this filter on or off.

Also, as a note: Node views have been recently fixed on #2217943: Views cannot be filtered by language of translation to have this filter, but it is not clear to me whether or not other entities have a language filter yet. We need to file other child issues of #2313159: [meta] Make multilingual views work if not. Is it OK for this issue to encompass all entities, or should it be specific to Node?

Let me clarify my thoughts: I agree having current language filters by default would make it easier for site builders to create views that behave more naturally in most use cases. So if the scope of this issue is just identifying which core views should feature (optional) language filters (and how they should be configured) or improving the UX around adding/configuring them (Jennifer's post above makes lot of sense), then I am all for it. What I think we should avoid is silently/automatically adding language filters around or, even worse, hardcoding multilingual filtering logic in Views' core. Multilingual is complex and we should make everything as configurable as possible (and, yes, UX plays a big role here).

Totally agree: We should not hard-code any language filtering in Views' core. I don't think anyone is advocating that, are they? This question is just about whether the language filters should be turned on by default, I think... assuming that these language filters are actually available in the first place.

So... I think we should actually postpone this issue until a few of the other Views multilingual issues are fixed (see meta issue #2313159: [meta] Make multilingual views work), and then come back and think about what makes sense for defaults for each core views config, and for each entity's wizard. The prerequisite to making decisions here and evaluating the options is basically, I think, that all entity views need to be working consistently and sensibly with languages:
- They all need to be working on the assumption that a row == (entity ID + language), not just entity ID
- Fields need to be working with this assumption and joined to the entity field data table, not just entity table
- All the entities need to have language filters available, which I think have only been added for Node.
- We also need to fix the display so that it is consistent and configurable with respect to language. This is not even true for Node views.

The meta-issue outlines the goals in more detail and has links to actual issues etc.; I just think this issue here is a bit premature until the rest of the system is set up, right?

I don't think anyone is advocating that, are they?

I had this impression from the parent issues, but if not then we are all on the same page :)

From #9

So... I think we should actually postpone this issue until a few of the other Views multilingual issues are fixed (see meta issue #2313159: [meta] Make multilingual views work), and then come back and think about what makes sense for defaults

Most of the issues on the Meta are complete, setting to Active.