Voting starts in March for the Drupal Association Board election.
Inthe proposal is of several steps. This is yet another break-out issue to solve the issue. By moving language responsibility from being baked into the configuration factory to its own system will allow implementers to swap this out when implementing other types of overrides, eg. domain. Also, this will result in a solid base implementation of overrides and *much less* code to run on sites where foreign languages are not needed. Also much simpler and more consistent base API and easier to understand OO interfaces.
- Remove special language handling from Config and ConfigFactory
- Move config language setting to LanguageManagers
- Implement language as it own overrides
Note thathas several other benefits that are not yet resolved here. For example, we are not introducing its own storage for language which is one of the key points there. This is so we can minimize the impact (which is already pretty big here).
User interface changes
- Config and ConfigFactory do not have direct language support anymore
- Cache handling in ConfigFactory is a lot more generalized
- Active language for configuration is now set on the LanguageManager
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 66,570 pass(es). View
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] 66,494 pass(es), 0 fail(s), and 44 exception(s). View
FAILED: [[SimpleTest]]: [PHP 5.4 MySQL] Unable to apply patch 2219499.20.patch. Unable to apply patch. See the log in the details link for more information. View