Minimum support for multilingual variables
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | language system |
| Category: | feature request |
| Priority: | critical |
| Assigned: | Jose A Reyero |
| Status: | patch (code needs work) |
This is a very minimum support to allow multilingual variables into Drupal core.
It does nothing by itself, just changes variable_get() function so any contributed module handling multilingual variables can define 'language_variable_init' function and throw its variables into the $conf array.
Also, it doesn't make any assumption about how this multilingual variables will be stored, updated or managed. It just tries to allow the feature without the 'dirty hacks' modules like i18n currently need to do for this.
If we had this in, we'd just need to add a language parameter to some variable_get() functions that need variables in other languages than page language, like the mail sending funcions... Provided there's a contrib module that handles them, they'll have their localized variables. Otherwise, nothing will happen.
| Attachment | Size |
|---|---|
| multilingual_variables_backend_01.patch | 1.64 KB |
#1
1. Dries did not like the -1 special parameter previously. In this settings it can even be NULL.
2. "} elseif" on the same line is not conformant to the coding style.
3. Once the global $language is set but the modules are not loaded, this code would set empty arrays for any languages used, which would make it impossible to grab the language specific variables later. Whether there would be critical variable_get() calls inbetween the $language code being set and the modules being loaded is a good question. Misbehaving modules like location views do such things already, but they also currupt the locale module processes, so I am not sure we need to protect from them here.
All in all, Dries needs to look at this, as it could be a controversial solution, however small it is.
#2
1. y 2. fixed. I didn't like the -1 either
About 3.
Not really, it only does when a variable is requested with language parameter, which won't happen during bootstrap. Wont do anything for page language (langcode = NULL).
So the first step the possible contrib module should do is to set the variables for the page language. Then just load other languages as requested.
Note that, as $conf is a global variable, localized variables for a language can be loaded any time, thus the only intention of the hook is to allow loading only the needed languages on demand.
Also, loading an empty array is the way to mark that language as loaded and not doing again the function_exists, it shouldnt have further impact...
#3
i've seen uglier :). seems acceptable to me after a quick read.
#4
Jose: what you write about (3) should probably be part of the phpdoc? I had the same question as Gabor and it wasn't quite obvious how you intended that to be used/worked around.
The PHPdoc should explain language_variable_init().
Also, there can only be one language_variable_init()?
#5
Answering to previous questions, I think this one is much more cleaner while still quite simple.
- Function language_variable_init() in bootstrap.inc, with per language caching.
- New hook_variable_init() for all modules, so any module can define localized variables.
#6
Well, variable_get() can be called way before modules are being initialized. Variables are initialized a lot earlier. So invoking hooks there is not an option. It would set your cache to an "invalid" value... By the looks of the code, it does not seem like it would work. Do I miss something?
#7
Guess it's too late and we need to have this done in D7. It's not the last part of the multilingual mosaique anyway... Would be a critical feature though, as multilinguality needs to be completed.