variables will not be saved in table i18n_variable

I believe this is due to a small bug in i18n_form_alter_settings(). At least in the 6.x-1.1 version, it will always return an array(), which means that i18n_form_alter() fails to add 'i18n_variable_form_submit' to $form['#submit']. The attached patch fixes this for me.

Looks not like a correct patch.

I confirm this. With 6.13/6.14 and i18n 6.x-1.1.

As far as I can tell the variables are not properly saved in the i18n_variable table. For one site I am working on, 5 out of 11 specified variables appear, on the second site 1 out of the same 11. Additionally, none, including those shown in the tables, react to any string search. At the same time they do appear marked as "multilingual variables" (for example on admin/settings/site-information. This after multiple cache clearings, refreshes etc.

Also unexpected string search results after installing the tcontact module (contact form) which uses i18n. The string search does not find current content for the contact form details in admin/build/contact/settings ("Additional information:" box), but does find obsolete original content (i.e. "You can leave a message using the contact form below.") deleted a long time ago (also after multiple cache clearings, refreshes, etc.).

This, after the other multilingual features do work: blocks, menu items, and the content. What can be done to make these variables translate?

subscribing.

@skylar
Where you able to get this working?

@ noelbush
@ hass
I'm not a php coder. But i can apply a patch and I can insert patch details manually, if I can be furnished the details.
Can you tell me what's wrong with the patch? Could you tell me what I need to apply to make the variables work?

Cannot reproduce it.

From #6: For one site I am working on, 5 out of 11 specified variables appear, on the second site 1 out of the same 11.

It seems you cannot reproduce consistently the bug yourself?

Check any other module (tcontact?) and confirm it happens in a clean i18n install.

Thanks for looking into it.

After checking more, the OP issue is different from mine.

I'm now able to make the multilingual variables work, I think had earlier not properly understood them. Yes, that described behavior was inconsistent.

The string translations remain problematic as in #442428: refresh strings in translation interface causes translations to be erased and then cannot be found in search, #541048: Translate all custom block titles (not only custom blocks). I think they are all, at least, similar. Hope the solution is in sight...

Closing this because
it is to unclear if it is a bug or not
if it is solved
the patch makes no sense.
due to inactivity for over a year.