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:

  1. 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]))
  2. 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
  3. Translation would be done using the normal "screen translation"-interface, by simply translating the content of the variable.
  4. Setting a variable xyz to translatable would be equal to setting a new variable "xyz_translatable" to true.
  5. Setting a variable xyz to non-translatable would be equal to deleting the variable "xyz_translatable".
  6. 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);
  }
}
CommentFileSizeAuthor
#13 core.385568.2.patch2.65 KBAnonymous (not verified)
#9 core.385568.patch2.38 KBAnonymous (not verified)
#9 core.385568-D6.patch2.03 KBAnonymous (not verified)
#7 core.translateVariable.patch2.44 KBAnonymous (not verified)
#6 core-d6.translateVariable.patch2.03 KBAnonymous (not verified)
#1 core-d6.patch2.3 KBAnonymous (not verified)
#1 core.patch2.23 KBAnonymous (not verified)
core.patch2.28 KBAnonymous (not verified)
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
Issue tags: +variable_get, +translatable
FileSize
core.patch2.23 KB
core-d6.patch2.3 KB

The 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.

pieterbezuijen’s picture

pieterbezuijen CreditAttribution: pieterbezuijen commented

I would very much like to see this in core:) Tnx for your work on this!

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
Version: 7.x-dev » 6.10

Thanks :)
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)

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

There 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.

tstoeckler’s picture

tstoeckler
he/him
Primary language German
Location Essen, Germany
CreditAttribution: tstoeckler commented
Version: 6.10 » 7.x-dev

The 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.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
Status: Active » Needs review
FileSize
core-d6.translateVariable.patch2.03 KB

Should work against latest from CVS.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
FileSize
core.translateVariable.patch2.44 KB

My apologies - I forgot to attach the D7-file.

Status: Needs review » Needs work

The last submitted patch failed testing.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
Status: Needs work » Needs review
FileSize
core.385568-D6.patch2.03 KB
core.385568.patch2.38 KB

My apologies.

tstoeckler’s picture

tstoeckler
he/him
Primary language German
Location Essen, Germany
CreditAttribution: tstoeckler commented

Just 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.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

I 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.

tstoeckler’s picture

tstoeckler
he/him
Primary language German
Location Essen, Germany
CreditAttribution: tstoeckler commented

Thanks 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...)

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented
FileSize
core.385568.2.patch2.65 KB

If 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.

chx’s picture

chx CreditAttribution: chx commented
Status: Needs review » Needs work

This 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/1827

chx’s picture

chx CreditAttribution: chx commented

It 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.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

Thanks 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

  1. setting of variables as translatable (clearly not all variables need to be translated)
  2. automatic and transparent translation of variables whenever they are retrieved (e.g. change to variable_get - otherwise many changes to modules would be needed)
  3. management of variable translations (e.g. adding a new page/set of pages that allows to set variables as translatable and allows to translate variable content)

I'm not totally sure how to manage changes to variables. I see the following possibilities:

  • Changing a translated variable will mark all translations thereof as outdated, the status page would then display an error "outdated variable translation present" (or something similar). This makes changes to variables more work for users but would be simple for module developers.
  • Adding a new form-field/form-field option to enter variable-values. Translatable variables would automatically be expended to multiple form-fields (one for each language) - changes to modules would be needed. This would throw work on module developers, but would perhaps be the most user-friendly solution.
    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.
  • Leave the variable translation up to the modules - module settings pages would have to be changed in order to allows translatable variables. In my eyes this would not be a good solution - it would throw work onto module developers and I would be willing to bet that more then one module would simply forget about this.

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.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

Okay, planing is complete. I am going to implement this in the next week.

sun.core’s picture

sun.core CreditAttribution: sun.core commented
Version: 7.x-dev » 8.x-dev
chx’s picture

chx CreditAttribution: chx commented
Status: Needs work » Closed (fixed)