Not sure if that’s a bug or if I’m missing something. I want to use the header locale switcher with a few select languages. But whenever I disable en(US) as interface language in the languages list, it is re-enabled automatically:
I guess having a fallback language in case there is no translation for an element makes sense. But why list it as one of the interface languages in the locale picker?
Mandated one way or another by Product if this plugin falls under their focussed remit as one of our plugins of “central concern”
Be captured in tests (not documentation that can be easily deleted or lost in a site migration), so there is no doubt for future developers who come across it.
if we can’t find anyone who thinks it makes sense,
and
if we can’t find anyone who knows why it is this way,
if the current functionality is not covered by tests,
then the functionality can be removed without further discussion.
I guess in this case we have three checkmarks
I propose to keep it as a fallback language (removing that doesn’t pass the “we can’t find anyone who thinks it makes sense”) test and remove it from the date picker (if it’s only the fallback language)
The discussion is not about having a fallback language or not, we all understand why that’s necessary. It’s about having it in the locale switcher.
I am aware of multiple forums where people don’t have anything to do with English (even dislike it), for instance a Belgian forum where the choices are Dutch, French or German.
The plugin adds the site setting multilingual_guest_language_switcher_footer_visible which sets the visible list. Just remove en from that list.
edit I see @manuel is specifically concerned with its appearance in the header dropdown. The header dropdown does indeed list all interface languages. So there would need to be a new setting to remove it appearing as an option entirely. That would be a new feature, but easy enough to do.
Just generally speaking though, I am still a little skeptical it is a good idea to remove a necessary option (which will always be present) as a visible option to users. I appreciate that some people really don’t like English, but I’m not sure that means you should hide it as an option completely from a product perspective, even though it’ll still be there as a fallback.
Because it is the global fallback there is always the possibility that some interface text shows up in English, regardless of what you do here. In that circumstance giving the user the possibility of lexical consistency is probably preferable from a UX perspective.
Keep in mind we’re talking about an option in a list here. If a set of users’ antipathy to English extends to the point of not wanting to even see it as an option in a list, despite it’s necessary role as a fallback, I think perhaps that’s indicative of another issue. But maybe I’m not being entirely fair in my perspective here (I haven’t had much coffee today).
That aside, adding a site setting to filter languages from the “full list” visible to users, which is the feature request here, is easy enough to do.
I think you’re focusing a bit too much on my “dislike” remark. Maybe you should have some extra coffee
It’s not about disliking or antipathy or “not wanting to see it”, it’s about people not understanding why this shows up and why it cannot be removed. Manuels start post in this very topic is a good example of the confusion it causes.
I think part of this is that, IIRC, the option to disable it used to also be disabled in the client too (i.e. the checkbox was disabled just specifically for English as an interface).
So perhaps the moves here are:
Fix the admin interface so that English can’t be disabled as an interface language (perhaps with a note explaining why).
Perhaps add a site setting to filter the full visible list of languages in the locale switcher.