Voting starts in March for the Drupal Association Board election.
Found this while working on. When config entities get imported from shipped defaults, they are resaved after instantiated in the import and therefore the undefined language default in ConfigEntityBase gets applied. So if the original shipped file did not include a language code, the entity will now (incorrectly) be undefined language. While configuration otherwise assumes English defaults if the langcode was not specified (see LocaleConfigManager::get(), ConfigNamesMapper::getLangcode(), etc.), this makes the configuration now *know* undefined instead of keeping to assume English.
We also cannot assume lack of language on ANY config entity because even RDF mappings, and view/form displays which do not have any human language text on them may take third party settings, which are impossible to predict if they would contain human language content or not. So unless we want to require people to set some concrete langcode on config entities when setting a third party setting that includes human language content, we need to keep assuming that all config entities are in a human language (and not 'und' or NULL).
Option 1. Fix the concrete files in core and document that config entities will not have the same missing langcode fallback at least while being imported.
Option 2. Fix the import code to add merge langcode: en to loaded default configuration before instantiating entities.
Option 3. Change the default in ConfigEntityBase to English and document it.
Patch implements Option 3 for now.
User interface changes
|#17||2451885-17.patch||83.07 KB||Gábor Hojtsy|
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 89,076 pass(es). View
|#17||interdiff.txt||3.15 KB||Gábor Hojtsy|
|#14||interdiff.txt||1.66 KB||Gábor Hojtsy|
|#14||2451885-14.patch||81.75 KB||Gábor Hojtsy|
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 88,997 pass(es), 7 fail(s), and 0 exception(s). View
|#11||2451885-11.patch||80.09 KB||Gábor Hojtsy|
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 88,869 pass(es). View