After having a look at the way the contact-module handles the creation of the contact-page, I wondered why there is no support for translatable variables. I am now proposing a patch that would enable multi-language variables in the following way:
- Per Default variables will not be translatable. For non-translatable variables, calling variable_get in the proposed way would result in a small overhead that I believe to be neglectable: One string-concatenation (variable-name . constant), one isset-check (isset($conf[new string]))
- For translated variables the overhead will be: One string-concatenation (variable-name . constant), one isset-check, one variable lookup ($conf[new_string] == true?), one is_null-check, calling t
- Translation would be done using the normal "screen translation"-interface, by simply translating the content of the variable.
- Setting a variable xyz to translatable would be equal to setting a new variable "xyz_translatable" to true.
- Setting a variable xyz to non-translatable would be equal to deleting the variable "xyz_translatable".
- The API stays compatible (adding one constant, adding one function)
I believe, that this patch would only add new functionality, without destroying any. This patch does not include changes to existing "translatable variables" (e.g. contact-module, calling variable_get(*,t(*)) which would change to variable_get(*,*)).
An alternative would be to not allow "translatable variables" - but then modules (both core and community) would have to adhere to this standard in order to allow fully translatable websites.
function variable_get($name, $default = NULL) {
global $conf;
$trans = $name.VARIABLE_TRANSLATABLE;
if (!(isset($conf[$trans]) && $conf[$trans])) {
return isset($conf[$name]) ? $conf[$name] : $default;
} else {
$cont = isset($conf[$name]) ? $conf[$name] : $default;
if (is_null($cont)) {
return $cont;
}
return t($cont);
}
}
Comment | File | Size | Author |
---|---|---|---|
#13 | core.385568.2.patch | 2.65 KB | Anonymous (not verified) |
#9 | core.385568.patch | 2.38 KB | Anonymous (not verified) |
#9 | core.385568-D6.patch | 2.03 KB | Anonymous (not verified) |
#7 | core.translateVariable.patch | 2.44 KB | Anonymous (not verified) |
#6 | core-d6.translateVariable.patch | 2.03 KB | Anonymous (not verified) |
Comments
Comment #1
Anonymous (not verified) CreditAttribution: Anonymous commentedThe same patch for Drupal-6.10 and against the (at the time of writing) latest Drupal-7-CVS.
Another variable that I needed "translatable" was site_name. It is a rather central variable - quoted e.g. in the TITLE-Field or in the print-module. Having the site_name in only one language looks rather ugly, this patch would allow to translate the site_name (if needed) by calling "variable_set_translatable('site_name')" once and afterwards translating the site_name using the normal translation mechanisms.
Comment #2
pieterbezuijen CreditAttribution: pieterbezuijen commentedI would very much like to see this in core:) Tnx for your work on this!
Comment #3
Anonymous (not verified) CreditAttribution: Anonymous commentedThanks :)
As far as I know, the new Forms API in Drupal 7 would allow similar options (well, in a different way, but with similar results) - but I would still like to see this in Drupal-6 (hence the version change)
Comment #4
Anonymous (not verified) CreditAttribution: Anonymous commentedThere is a solution at http://drupal.org/node/313272 - which I personally believe to me less user-friendly then my version.
Still - this also fixes the issue at hand.
Comment #5
tstoecklerThe link that you provided is not an issue, it is a handbook page that tells you how to work around the current state where you are not able to translate variables by default. I think this a very much needed feature for Drupal7.
I am almost certain though, that people that are involved in the ongoing internationalization improvement work for Drupal 7 have thought about this.
Maybe you should ping Gabor Hojtsy or Jose Reyero about this issue in IRC or something.
But don't get me wrong, big +1 from my side.
Comment #6
Anonymous (not verified) CreditAttribution: Anonymous commentedShould work against latest from CVS.
Comment #7
Anonymous (not verified) CreditAttribution: Anonymous commentedMy apologies - I forgot to attach the D7-file.
Comment #9
Anonymous (not verified) CreditAttribution: Anonymous commentedMy apologies.
Comment #10
tstoecklerJust by reading the patch: Did you mix up $trans and $translatable sometimes or did I just not get something. If im correct $trans should be replaced with $translatable in every occurence.
Comment #11
Anonymous (not verified) CreditAttribution: Anonymous commentedI apologize for this naming - $trans is the name of the variable used to indicate whether the variable is translatable or not. (e.g. if the variable 'fooba' is translatable, the variable 'fooba_translatable' will be set.
$trans will contain 'fooba_translatable'.
$translatable is used in variable_set_translatable to indicate whether to active (true) or deactivate (false) translatability for the given variable.
e.g. calling variable_set_translatable('fooba') or variable_set_translatable('fooba',true) will include in the variable 'fooba' to be translatable. Inside this method $trans will contain 'fooba_translatable' and $translatable will be true.
I'd gladly call $translatable -> $setTranslatable or $newTranslatable, and $trans -> $isTranslatable or $variableTranslatable or $translatableName or something like this, if this is clearer.
Comment #12
tstoecklerThanks for clearing that up. I'm not into function naming conventions. Maybe just describing the functions just as in #11 in code, would also help. (Or did is miss something and it's already perfectly described in code? In that case, sorry...)
Comment #13
Anonymous (not verified) CreditAttribution: Anonymous commentedIf the usage of those variables (and functions) is not clear from reading through the patch, I obviously made some mistakes. So - either way - no need to apologize and a big thanks for the feedback!
Regarding the function names: variable_get is predefined and I believe variable_set_translatable to fit into the naming patterns :)
A version with comments and a different if-structure (might be easier to read) is attached.
Comment #14
chx CreditAttribution: chx commentedThis needs a lot of work. Aside from coding style issues, the fundamental idea is IMO wrong -- you can not send variables through
t
. Please read http://groups.drupal.org/node/1827Comment #15
chx CreditAttribution: chx commentedIt might be a duplicate of #361597: CRUD API for locale source and locale target strings which is, alas, quite stalled.
Edit: or not. Re-reading that issue I find that I asked for specific patches instead of generics so actually it might be better to solve the variables problem here, but it needs to be done right.
Comment #16
Anonymous (not verified) CreditAttribution: Anonymous commentedThanks for your input. I agree that
t()
is not perfect for this job - many users would not know how to add translations and the translations table would be clustered with dirt (e.g. spelling corrections) - but it would solve the problem at hand quickly (e.g. allowing the translation of the message on the contact formular, which was the original motivation behind this patch) and would not need any changes to existing modules.I would really love to see some variable translation mechanism in Drupal 7. Would a new system stand a change of being incorporated?
Just for clarification: As far as I understood your last post in #361597: CRUD API for locale source and locale target strings you do not want a generic translation mechanism, thus we would have to develop our own? I'd be willing to contribute to a generic system or develop a specific one - but I'd love to first known which one it will be ;)
I would be willing to develop a system that allows
I'm not totally sure how to manage changes to variables. I see the following possibilities:
I dont see a way to automatically accommodate this - AFAIK there is currently no way to tell whether any given form field maps to a Drupal variable or not.
Alternative propositions?
--edit: In addition one would need a way to allow a "non-english default language", but that would not be a major problem.
Comment #17
Anonymous (not verified) CreditAttribution: Anonymous commentedOkay, planing is complete. I am going to implement this in the next week.
Comment #18
sun.core CreditAttribution: sun.core commentedComment #19
chx CreditAttribution: chx commented