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.
But on the form provided by variables, the value isn't updating.
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.
Comment | File | Size | Author |
---|---|---|---|
#19 | variable-use_current_realm-2174687-19.patch | 887 bytes | _test3r_ |
| |||
#17 | variable_realm.2174687.17.patch | 1.13 KB | weseze |
#14 | variable_realm.2174687.14.patch | 1.13 KB | weseze |
#11 | variable_realm.2174687.10.patch | 1.26 KB | cutesquirrel |
#3 | 2174687-variable_admin_form_realm-01.patch | 1.26 KB | Jose Reyero |
Comments
Comment #1
malks CreditAttribution: malks commentedFurther 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.
Comment #2
malks CreditAttribution: malks commentedI 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.
Comment #3
Jose Reyero CreditAttribution: Jose Reyero commentedPlease, give a try to this one.
Comment #4
thesame- CreditAttribution: thesame- commentedI 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?
Comment #5
Jose Reyero CreditAttribution: Jose Reyero commentedThe 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?
Comment #6
Jose Reyero CreditAttribution: Jose Reyero commentedCommitted the patch.
Comment #9
fietserwinI encountered the same error, it is still not solved:
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".
Comment #10
XandieL CreditAttribution: XandieL commentedHi,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 likeScratch that, why not implement it's own permission?
Comment #11
cutesquirrel CreditAttribution: cutesquirrel commented#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.
Comment #12
cutesquirrel CreditAttribution: cutesquirrel commentedComment #14
weseze CreditAttribution: weseze commentedThis patch should pass the testbot. (removed the "sites/all/modules/contrib/variable" part)
Comment #15
weseze CreditAttribution: weseze commentedComment #17
weseze CreditAttribution: weseze commentedCorrected the "git diff" line.
Comment #19
_test3r_ CreditAttribution: _test3r_ commentedRetrieve current realm via variable_realm_params. Manually applying this patch worked for me.
Comment #20
voj CreditAttribution: voj as a volunteer commentedDuring 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.