Hi,

Firstly, sorry for the cross posting, but I did not get a response over at this i18n issue so I am hoping for more of a response here.

I've installed a base Drupal install with just the minimal i18n and Variable modules. Going to admin/config/regional/i18n/variable I've allowed Site name to be a multilingual variable and set up another language (en-AU). Going to admin/config/system/variable/edit/site_name?variable_realm_key_language=en-AU shows the same value as going to admin/config/system/variable/edit/site_name?variable_realm_key_language=en even though the correct value is being saved in the database.

Further to this, it actually works if I go to the base form, i.e. admin/config/system/site-information?variable_realm_key_language=en and admin/config/system/site-information?variable_realm_key_language=en-AU both show the values stored.

Working

But on the form provided by variables, the value isn't updating.

Not Working

Also more info, if I go to the language version of the site (i.e. /au for the Australian site), the default that it shows in the broken situation is the AU value for all cases.

Thanks,
Anthony.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

malks’s picture

Further to this, if I create my own form for setting the variables that works fine, so it's only support for the variable admin created helper forms that is broken.

Regards,
Anthony.

malks’s picture

I had it pointed out to me that there is another path for updating i18n variables, namely admin/config/system/variable/realm/language/edit which correctly respects the language that you're setting. That is, going to admin/config/system/variable/realm/language/edit?variable_realm_key_language=en-au will show the AU values of the variable as stored.

Jose Reyero’s picture

Status: Active » Needs review
FileSize
1.26 KB

Please, give a try to this one.

thesame-’s picture

I don't really get this. Why should we check only for admin paths and why should it check for 'administer site configuration'.

I have created a custom settings form for limited users and wanted to use it's fields as multilingual variables. And it took me a while to realize why it works only for admin users.

If user have permission to access given page, why should there be any other permission checks?

Jose Reyero’s picture

I don't really get this. Why should we check only for admin paths and why should it check for 'administer site configuration'.

The module is rewriting forms but skipping some 'variable administration' ones.
We check for admin permission before doing any variable realm switching, this is not something for anyone to play with.

But the question, does the patch work or not?

Jose Reyero’s picture

Status: Needs review » Fixed

Committed the patch.

  • Commit 83c00d0 on 7.x-2.x:
    Issue #2174687 by Jose Reyero | malks: Viewing multilingual variables...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

fietserwin’s picture

Version: 7.x-2.3 » 7.x-2.x-dev
Status: Closed (fixed) » Active

I encountered the same error, it is still not solved:

  • It does work on forms from other modules, like the form "site information" in the issue summary.
  • It does almost work on admin/config/system/variable/realm/language/edit[?variable_realm_key_language={language_code}]. Almost as for English it seems to fall back to defaults as set in the hook_variable_info().
  • It does not work on admin/config/system/variable/module/{module_name}[?variable_realm_key_language={language_code}] even not if the query part is there. The description text does say "These are global default variables. To edit variables for a specific realm go to Variable Realms", which suggests that it should not work. But then, the fieldset directly below ("There are multilingual variables in this form") offers links to the various languages (with the default language highlighted), so it is suggested that you are actually editing the values for the highlighted language.

So if that fieldset is supposed to work on this specific form, we should make it work, otherwise it should not be added to this form, such that there can be no confusion and people know that they will have to click on the link "Variable realms".

XandieL’s picture

Hi,

I also encountered this bug. Why don't we make the it's hook_init alterable? Sorry. I don't know how things work here. Something like

<?php
function variable_realm_init() {
  $perm = 'administer site configuration';

  drupal_alter('variable_realm_init_user_access',$perm);

  if (arg(0) == 'admin' && (arg(3) != 'variable' || arg(4) != 'realm') && ($params = variable_realm_params()) && user_access($perm)) {
    foreach ($params as $realm_name => $realm_key) {
      variable_realm_switch($realm_name, $realm_key, FALSE);
    }
    variable_realm_rebuild();
  }
}
?>

Scratch that, why not implement it's own permission?

cutesquirrel’s picture

#4 is totally right : we should rely on a custom permission, to allow users to manage i18n variables without having the "administer site configuration" permission.
Here is a tiny patch.

cutesquirrel’s picture

Status: Active » Needs review

Status: Needs review » Needs work

The last submitted patch, 11: variable_realm.2174687.10.patch, failed testing.

weseze’s picture

This patch should pass the testbot. (removed the "sites/all/modules/contrib/variable" part)

weseze’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 14: variable_realm.2174687.14.patch, failed testing.

weseze’s picture

Status: Needs work » Needs review
FileSize
1.13 KB

Corrected the "git diff" line.

Status: Needs review » Needs work

The last submitted patch, 17: variable_realm.2174687.17.patch, failed testing.

_test3r_’s picture

Status: Needs work » Needs review
FileSize
887 bytes

Retrieve current realm via variable_realm_params. Manually applying this patch worked for me.

voj’s picture

Status: Needs review » Closed (outdated)

During collaboration with @XandieL it seems that I cannot replicate the issue any more.

It seems that when switching on language via Path prefix language code AND the parameter variable_realm_key_language isn't set, it will automatically switch with the language.