Improve the options in the views language filter

Wondering if something as simple as this could work? It doesn't seem any of these dynamic options really make a ton of sense for the exposed filters options, except maybe the 'Interface text language selected for page' for the use case of selecting that by default.

Moving to MR for easier review.

Seems to have test failures.

Added commit which should fix the failing tests

Thanks @laurii

Moving to NW for the remaining tasks

Discuss if we can (optionally?) remove some of the options.
Which ones we can/should remove and how we should do that.

Even tagged for "Usability", I'm not sure "Improve the options..." qualifies as a bug. But since it's currently called a bug, let's smash it. 😉

I think this is a usability bug so +1 for #20 😊

Based on #2 and #3, the MR implements a solution that removes all of the non-language options out from the exposed filter. It is still possible to filter based on the non-language options when using non-exposed filters.

Tested this per @lauriii request.

While reading the issue, I was afraid we were removing options needed when building a site where you still don't know all languages as @Berdir pointed in #2, or when providing views in contrib modules. But this only affects exposed filters, so we should be good.

My only concern is that in my experience, exposed language filters in views is something that you are providing in 90% of cases only for editors/admins of the site, not for visitors. And those probably know what those options are, and missing the options can make them think they did something wrong or something broke their site.

Anyway, I don't see any use case where this stops to provide functionality we had, so I'm happy to explore this. If users complain, then we are still able of reverting the change.

Tested the functionality and looks great. Has enough test coverage. Not sure what needs work, but based on the above this LGTM.

As a (former) maintainer of the Lingotek module, this doesn't affect it, as it doesn't use views for its management pages. But TMGMT uses views and language exposed filters, so I'd like to know Berdir's point of view before merging this as it might change TMGMT users experience.

I agree with @penyaskito that this could loose features people use in admin views for content management, etc. Those ideally default to the page's (admin) language or the user's language, etc. rather than a specific language IMHO. Its been a while I used Views exposed filters, but is it not the case, that the admin of the view can pick which options will be exposed? In that case making a default of only the configurable languages makes sense but I am not sure removing the possibility of the other options altogether is a good idea.

TMGMT doesn't use views anymore and I agree that this is very confusing and in *most cases* not needed.

This filter is exposed by default on /admin/content I think, so it's part of the default experience for any content editor, not just admins. For a specific site, you can manually limit it to a specific set of languages, but that needs to be updated when you add languages.

That said, maybe this should be an explicit setting, possibly even enabled by default and not just the expose setting. Of course that will make this much more complicated, with schema changes, update functions, ...

The problem is that we can't really change the default experience to anything more sensible with the current options because otherwise new languages being added to the site wouldn't be automatically added to the exposed filter. I think we could try to implement something along the lines of #2 which allows site owners to customize this based on their requirements.