Only show the language widget on entity forms when more than one language is available

No test coverage yet but here's what the change itself looks like.

A counterpoint would be that if you've mistakenly only got one language, having the somewhat useless element might be a hint as to what the problem is, but personally I think the tidier form outweighs this.

The counterpoint mentioned in #2 seems like a valid argument, so this probably needs usability review. Otherwise the patch makes sense from a developer's point of view :)

Agree this seems like a good update to have.

There are a few different points of view to this, especially if single language is only a temporary phase.
- Having less information on the form vs. having the form change.
- The same effect could be achieved by not showing the language selector on the form. It may be confusing if site builder adds the language selection to the form but this does not appear.
- There may be modules that restrict languages per user (maybe Allowed Languages does this) or some other use cases where language information is useful to have even if only one option.

I would go with a softer approach by making this configurable and on by default. We already have a setting for including "Not specified" and "Not applicable".

Current:

New version:

I'm not sure how often the configuration proposed in #6 would actually be useful. Since it's unclear if the configuration option would be helpful, I think we should first try to go with an approach that doesn't provide the configuration option. We can always add that later if it seems something that's worth adding.

Given that the "Include locked languages" setting is enabled by default, we could try to address #2 by displaying a warning in the widget settings when the checkbox is disabled and there's only single language.

I guess there's another way to get to this point which is that you remove a language, but that seems something that happens less often. That said, it makes sense at least to me that if I have only one language left, that I can no longer select the language.

FWIW, the language switcher block already has this functionality. See \Drupal\language\Plugin\Block\LanguageBlock::blockAccess.

There is actually also an existing setting content type / vocabulary. For "An example would be updating an existing site to have multi-lingual content, but not wanting to enable additional languages yet." one would just fix the language appropriately for the content and uncheck the box "Show language selector on create and edit pages".

I am a little bit confused in which real world scenario this proposed code change would really be useful compared to existing configuration. I wonder if there is something I'm missing from the problem description? I'm looking at this from node/term perspective. I didn't check where else this would affect the site.

Having intentionally enabled translation, decided to show the widget but then use code to hide the widget feels a bit odd a combination. When one enables translation there is already decision wether or not to allow selecting the language.

A couple of lines of code isn't much and doesn't slow down the system so that it could be noticed by the human eye and uses hardly any extra electricity, but it is still a bit extra to save a few clicks on edge cases. Current version supports also starting to allow languages gradually but just not site wide change with a single click. Then again the change would usually go to production via CI/CD pipeline in configuration yamls.

But it's not a big deal, I guess.