Minimum support for multilingual variables
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | language system |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Jose Reyero |
| Status: | needs work |
| Issue tags: | i18n sprint |
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.
#8
Adding this to my tracker, so I'm not losing sight of it during my next Drupal hacking round. (A.k.a., subscribing.) =)
#9
#10
Updated the patch for current HEAD
Anyway, we have still time to do something better for Drupal 7, I've just updated the patch just in case someone wants to build upon it.
#11
I have written an alternative solution at #385568: Translatable Drupal-variables - sorry, missed this issue previously.
#12
#10 still applies, but with some offset. Here's a re-roll without the offset. :)
Also, there should probably at least be some unit testing for these functions.
#13
I am working on a solution for variable translation (e.g. own page for variable settings and translations, allows for variables to be configured by the module developer and/or the user, etc) that will not add incompatible API-changes ($conf will work as expected (w/o translated variables), variable_get etc will work as expected). It adds a "system inherent" translatability for variables and gives module developers the possibility to add own translations, settings, etc. (Reason: I dislike solutions that rely only on module developers - some module developers will forget to add multilanguage support to their variables, etc, thus a "developer independent" solution is needed.)
@Jose Reyero, Freso: Thanks for the work done so far!