- Configuration settings may need to be changed depending on language settings.
- Settings marked as translateable should be able to be arbitrarily saved or retrieved for any of a site's enabled languages.
This issue is now [meta] and produced have 3 options
Discuss away in the relevant issues.
- We will need to handle both translated text and internationalized data (different depending on the specified language).
- We will want to specify which settings are internationalized. The default will be that settings are not internationalized.
- Configuration files will have a language extension added to them. For instance, English configuration of the performance settings would be stored in system.performance.en.xml whereas Swedish performance settings would be stored in system.performance.se.xml.
- The language chosen at install time will have its configuration installed, and any subsequent language configs will only contain diffs from the site default language.
- A new field for language will be added to the active store.
- For each file and language combination, configuration is loaded and saved into the active store. For the site default language, the complete configuration is loaded and saved. For other enabled languages, the diffs are merged into the default configuration and saved.
- Pieces of configuration that can be internationalized will be marked as "translateable" either in the XML attributes or in some other similar mechanism if XML disappears.
- Items that are translateable will always be saved into the configuration settings of the language the user is currently browsing in. Items that are not translateable will be always be saved into the site default language configuration.
- All public APIs for config CRUD operations will have a language parameter added which will default to the site's default language.
- Originally it was thought that we could save all languages in an individual file, with the languages set as attributes like this:
<site_name lang="en">I am awesome!</site_name>
<site_name lang="se">Jag är grymt!</site_name>
However this means that when languages are installed, all their configuration will have to be merged into existing files and saved, which is much more complicated than the current solution which just has them copied at install-time. The downside of the current solution is that you will at times have to push multiple files to encompass all changes to a piece of configuration. I think this is a good compromise to keep the architecture simpler.
- Another downside of this system is that it has a second place where we store translated text aside from the .pot files.
- This system is similar to (albeit simplified from) the way that Java Resource bundles are internationalized (see http://java.sun.com/developer/technicalArticles/Intl/ResourceBundles/).
- At one point yched brought up the option of replacing the strings in the configuration files with placeholders, storing the internationalized versions elsewhere (such as in the .pot files). The ramifications of such a change have not been fully thought out.
- Past discussion can be found at http://groups.drupal.org/node/185609