Closed (fixed)
Project:
Commerce Core
Version:
7.x-1.x-dev
Component:
Cart
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
18 Mar 2013 at 21:10 UTC
Updated:
25 Jul 2013 at 04:41 UTC
Jump to comment: Most recent file
Comments
Comment #1
jsacksick commentedHere's a working patch that works with i18n, the customized labels are fully translatables with i18n.
Comment #2
jsacksick commentedThis patch moves the title logic into a separate api function called commerce_cart_attribute_widget_title that takes the field instance as argument.
Comment #3
rszrama commentedI tested the patch and turned up a notice if the Field translation module isn't enabled: "Notice: Undefined index: field in _locale_translate_seek() (line 1931 of /Applications/MAMP/htdocs/kickstart/includes/locale.inc)." Easy enough to fix by making the dependency on the module if we're going to use that group.
However, looking at the patch in #1147690: Make "Add to cart" button text a display format setting (configurable at the field level by content type), it doesn't use string translation at all. Apparently we can just register the setting in the object info and have it automatically be picked up by i18n or something. That would indicate we don't need to use the String translation module at all like your patch currently does.
Comment #4
jsacksick commentedHere's an updated patch, we can't reuse the exact same logic as in #1147690: Make "Add to cart" button text a display format setting (configurable at the field level by content type) because if we implement the
hook_i18n_object_info_alter(), i18n won't find the source string to translate because it will try to find the source string directly in $instance['attribute_label'], but our source string is located in the commerce_cart_settings array. That's why we need to use the alter hook.Apparently we don't need to use the
hook_field_update_instance()to track the modification of the string, this is done automatically by i18n_field itself.With this code we're adding a translatable instance property 'instance_label' but we're taking the source string in the commerce_cart_settings array. We can't do that directly in the
hook_i18n_object_info_alter()Comment #5
rszrama commentedThis seems to mostly work, but I get the following notice and no label when I try to view a node with my attribute field in the default language:
Comment #6
rszrama commentedHmm, and I tried this again, but now I'm getting that notice for either English or French. I also can't even get my custom title to show up in the strings list to translate. Sorry, but I'm going to go ahead and postpone this until post-1.6, as I don't have time to work through it all right now.
That said, as written, I don't see why this should depend on the "Field" group / "Field translation" module. Shouldn't it be possible without that? Also, what if we did just use object translation and simply copied the object from our commerce_cart_settings array into the instance array and passed it through for translation? Just because we store the label in one place doesn't mean it must remain there during translation, especially since the translation itself isn't stored in the object.
Comment #7
rszrama commentedJust leaving a note in here to compare this against the work bojanz is doing to translate checkout completion messages using i18n_string here: #1196488: Allow checkout completion message to be translated
Comment #8
bojanz commentedJonathan's approach is fundamentally correct. We should use i18n_field here.
I found several problems in the patch:
1) The attribute label should default to the instance label, currently it doesn't.
2) commerce_cart_attribute_widget_title() always gets the same instance, so the label returned is the same for all attributes.
3) The notice that Ryan reported.
Rebuilt on top of #1121722: Improve DX of instance translation.
Patch and interdiff attached.
We might also want to rename commerce_cart_attribute_widget_title to commerce_cart_attribute_label or something similar, I don't like the label / title duality.
Comment #10
rszrama commented#8: 1946302-8.attribute-label.patch queued for re-testing.
Comment #11
rszrama commentedI may re-roll this to standardize on title as opposed to label, because form elements have titles while formatted fields have labels.
Comment #12
rszrama commentedAlrighty, here's a re-roll that standardizes on "attribute_widget_title". Tested as working but letting testbot have a say.
Comment #13
rszrama commentedCommitted.