This is a follow up to #1414554: Translation set not being saved properly on the product entity which fixed part of the problem.
Not fixed by the above patch is the problem of translatable fields content being lost when creating(!) a product in a language, other than site-default.
After updating to 1.2 I've revisited the issue and have indentified another culprit in commerce_product_ui.module (line 528) :
-- start reading from the LAST comment (bottom up) --
/**
* Submit callback for commerce_product_ui_product_form().
*
* Checks if translation is enabled for the product and handles language changes.
* Since this handler may change the language of submitted form values it should
* be the first submit handler called.
*
* @see commerce_product_ui_form_commerce_product_ui_product_form_alter()
*/
function commerce_product_ui_product_form_translation_submit($form, &$form_state) {
// Get an array of available languages.
$available_languages = field_content_languages();
list(, , $bundle) = entity_extract_ids('commerce_product', $form_state['commerce_product']);
foreach (field_info_instances('commerce_product', $bundle) as $instance) {
$field_name = $instance['field_name'];
$field = field_info_field($field_name);
$previous_language = $form[$field_name]['#language'];
// Handle a possible language change; new language values are inserted and
// the previous values are deleted.
if ($field['translatable'] && $previous_language != $form_state['values']['language']) {
$form_state['values'][$field_name][$form_state['values']['language']] = $form_state['commerce_product']->{$field_name}[$previous_language];
/*
the above line is causing the problem, as the object $form_state['commerce_product']->{$field_name} is not necessarily available, thus setting the value to 'null'.
Replacing it with the following assignment solves the problem of translatable fields ending up empty:
$form_state['values'][$field_name][$form_state['values']['language']] = $form_state['values'][$field_name][$previous_language];
*/
$form_state['values'][$field_name][$previous_language] = array();
}
}
}
Since I dont know if it is generally save to rely on the values array, rather than the $form_state['commerce_product']->{$field_name} attribute, I've wrapped the whole thing in a conditional, to only use the values array when $form_state['commerce_product']->{$field_name} is not set (which happens to be the case for all translatable fields on my product).
It works well for me, but I can't vouch for this making sense in broader terms.
So if someone with a better understanding of this stuff would like to review, I'd be most happy.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | field-translation-1434512-3.patch | 1.72 KB | helior |
| #1 | 1434512.patch | 1.22 KB | cjoy |
Comments
Comment #1
cjoy commentedComment #2
rszrama commentedTagging.
Comment #3
helior commentedI did experience loss of data as well, but it was explicit loss of data, if that makes sense. It might be that this is really a UX problem.
The setup requires the Entity Translation module to be enabled, Commerce Product entities enabled to be translatable in admin/config/regional/entity_translation, and multilingual support is "enabled via Entity translation" in the product type edit form...
So, Product A can be assigned the English language, and then have translation strings in French, via the Translate tab on the product edit page. However, if the content editor changes the language of Product A from English to French, and also adds new French translation string to the product edit fields directly, then both previous English and French translations will be lost.
Entity Translation guards against this UX blunder for nodes by excluding the option to switch to languages that have existing translations. If Commerce Product follows the same pattern, we can guide users to use the Translate tab for translations, and not accidentally clobber existing translation strings.
Btw, the test case you mentioned regarding creating a new product in language that is not the site default – works identically to products which are being edited. I've inspected and walked through the code during the save execution, but I can't confirm that data is lost on its own, unless it's from the above scenario.
Comment #5
helior commentedUpdating version to dev so it can pass tests.
Comment #6
rszrama commented#3: field-translation-1434512-3.patch queued for re-testing.
Comment #7
rszrama commentedHmm, I actually can't figure out how to make the module work in general. The only thing it's letting me "translate" is an image field, and even adding a text field to my product type didn't make it show in the translate tab. That said, I trust your judgment here. Will see if cjoy has anything to say about the solution and commit once we get a confirmation.
Comment #8
helior commentedOh whoops, I forgot to mention that there's a checkbox in each field setting that asks if you want that field to be translatable. That's probably why your text field isn't showing up under the translate tab.
Comment #9
rszrama commentedlol I looked for that, but obviously not good enough. I did hear back from cjoy, and he said he'd try give the patch a look, too. : )
Comment #10
cjoy commentedThe patch at #3 works as intended and is a good way to save the user from accidentally overwriting existing translations. Good stuff!
However, it does not impact my issue at all. The data loss I observe (and fixed with glue and a shoestring as per #1) takes place in the process of saving the initial data set (create product).
I think I already double checked this on a clean install back then, but I will try to reproduce my issue once more on a vanilla(ish) install and provide that setup for confirmation.
Comment #11
cjoy commentedCan't reproduce my #1 issue on a vanilla install with 7.x-1.x-dev either.
... I might have to step through both installs, the affected production site and the vanilla site, when time permits. Now I am curious again as to what causes this :)
Until then, please feel free to tag this issue "closed (cannot reproduce)" (won't close it now, as there is a patch to a different issue being discussed still).
Thanks.
Comment #12
rszrama commentedAlrighty, I committed the patch based on your review and will close this one out. Thanks for taking the time to investigate the bug further. : )
Comment #12.0
rszrama commentedclarification of issue