Internationalization of configuration [#1320012]

I recently had a discussion with gabor, plach, jose and webchick about internationalization in the config system. The summary of this discussion has been posted at http://groups.drupal.org/node/185609.

This meta-issue will track the coding needed to be done to accomplish this. While talking is still going on, it seems likely that at least the following will need to happen.

- XML file names need to include some information about language and possibly locale
- These files will only contain the translated or internationalized data
- When loaded into the active store, the internationalized data needs to be merged with the default files
- We still need to figure out what to do about the problem of essentially needing one active store per language on multiple language sites.

Comments

Comment #1

michaelfavia CreditAttribution: michaelfavia commented 2 November 2011 at 06:39

I feel like i18n is just one context of a few we might be interested in tracking and managing. Other examples might be:

device type (mobile, desktop, tablet)
region
screen size (small, medium, large)

Each context could be queried from the WSCCI initiative so that our configuration could adapt so that the default number of artuicles on the home page is smaller for mobile or the currency units are changed for the US but all other settings fall back to the more generic versions if not specified.

Android does a good job of implementing this type of a system for strings, graphics, layouts, etc:
http://developer.android.com/guide/topics/resources/providing-resources....

Comment #2

Jose Reyero CreditAttribution: Jose Reyero commented 24 March 2012 at 09:57

I agree that it is interesting to have different realms / domains besides language. Anyway with or without 'realms', there are a few things we need to decide:

1. File storage.

We could add it to the file name like system.performance.[language=es].xml

Or we can have it as folders like config/language/es/system.performance.xml

I am more inclined to the second one, folders as it looks cleaner and it seems more flexible an easier to move files around.

2. Database storage. We can add one ('language/es') or two fields ('language', 'es') and maybe a weight (that will be updated according to realm 'weight' so we can load the configuration for the current realms in a query and in the right order.

About how to handle these concepts, I would propose something (the idea, not the api itself) as how it is done in variable module (variable_realm submodule), http://drupal.org/project/variable.