ConfigNamesMapper::getLanguageWithFallback() logic not clear

No, if the language was not possible to load AND it was English, then we can make it appear like English. If we cannot load the language and it was NOT English, we don't want to make it appear as if it would be English. It should probably throw an exception in that case (if empty($language) && $langcode != 'en', since then you have a config file for a language not present on your site. Eg. you created a View in German and then removed German from the site but not the View, then we don't want it to appear as if it is English. Your patch makes it appear as English...

It would not hurt indeed to have tests for this case, but basically this is a shortcut for lazy config developers who do not include a langcode key in their file, and makes us assume those files are English (even if English is not present on the site as in when you install in German). The same assumption exists in the locale module in core when parsing config files, if there is no langcode, we assume it is English.

That would only work for the lack of langcode case, not when English is not present on the site such as when installing in German

So this logic is supposed to cover two cases:

- config file without langcode code (lazy module coder) => should assume English
- config file with a langcode not on the system ONLY IF the langcode is 'en' => assume "Built-in English specifically"

The way this is achieved is the following:

- getLangcode() defaults the langcode to 'en' if not present in the file (covers the first point)
- geLanguageWithFallback() attempts to covert the langcode to a language object and if it fails AND the langcode was 'en', it will fake a "Built-in English" for the sake of display

So the combined behavior of getLangcode() and getLanguageWithFallback() is what achieves this logic. In getLanguageWithFallback() the langcode will never be empty, because getLangcode() always sets it. So we'll have a langcode. Then we try to load the language. If it was English, we want to use the runtime configured version of it (eg. user may have changed the label to something else and also then custom config files may be created in English, so those files would not be built-in English). If the language cannot be loaded and it was English then we assume that file was a shipped config file, ie. the user did not create English config files on a site if English is not present... So we say "Built-in English". Then if the langcode was not 'en' but we could not load the language, the return value will be null I think or whatever language_load() returns for an unrecognized langcode. We may or may not want to throw an exception then.

Here is some docs to help cover this :) What do you think?

Committed these docs, please reopen if you have better ideas :)

Retitled for accuracy.