Over inwe've been exploring providing a separate storage for language configuration overrides. The approach has several advantages as:
- config schema just work as the config object name is the same
- the amount of config objects in each storage does not become a huge mess - think of how many files a staging directory could contain on a big multilingual site
- fixes issues with key length since we don't have to prefix language overrides
However the approach falls down when trying to make it work with config synchronisation because:
- If we are only importing language overrides at the moment this will not work because the config sync page is only looking for changes in the regular config storage
- The language config sync code has to make assumptions about how staging in structured and that it is in fact a file storage
- If another module was providing overrides through a similar method of storing in pseudo config files it is going to have to write much of the same code
- If the language module is not enabled then it is totally impossible with this approach for the sync process to inform the user what is going to happen if you stage installing language and create language configuration overrides in the same sync
Add collections to config storages. A configuration storage can contain multiple sets of configuration objects in partitioned collections. The collection key name identifies the current collection used. The storage interface contains the method
getCollectionNames() to list all the available collections. This means that config sync will be able to compare staging to active even if the module that writes to that particular collection is not installed. So for example, if staging contains a collection called
language.de, we can discover this and display to the user that this configuration will be synchronized even when the language module is being installed at the same time.
createCollection() which returns a new instance of the storage with the collection set. It does this to avoid side effects caused by the storage object being injected into each Config object - changing the collection on the storage of one Config object would change them all.
For databases this will add an extra column and in file systems this will use directories.
The patch here just adds the ability and tests it. Implementation of language to use this should be done in
User interface changes