Options from product fields on the add-to-cart form might not translatable

You mean translate the label of the price field when it's displayed on the node?

Ok, there are a couple of open issues related to translation. Are you using a field translation module?

Ok, there are a couple of open issues related to translation. Are you using a field translation module?

Entity Translation installed - Commerce product set for translation. Still i can't find the way to translate the "Price" label.

Subscribe.

Same issue.
Subscribe

I had problems with all the dropdown field labels because they did not translate. Changing line 1578 in modules/cart/commerce_cart.module solved the problem for me. I'm not sure that's the way one should translate stuff, so I won't make a patch. But it works. I have changed the line starting with #title.

  else {
            $form['attributes'][$field_name] = array(
              '#type' => $data['commerce_cart_settings']['attribute_widget'],
              '#title' => check_plain(t($data['instance']['label'])),
              '#options' => array_intersect_key($data['options'], drupal_map_assoc($used_options[$field_name])),
              '#default_value' => $default_product_wrapper->{$field_name}->raw(),
              '#weight' => $data['instance']['widget']['weight'],

Use the i18n fields module, part of the i18n suite to translate those elements.

Hello,

I don't think that this option is the best one.
It isn't relevant to install this module to only translate 3 or 4 strings whereas the core translate interface do it perfectly.

Don't you agree ?

Is there a reason to not code the t() function in the fields definition like czigor did in #10 ?

Thanks for your work.

Yeah, it's a limitation of the function itself. It's only supposed to be used for string literals, meaning the actual string, not a variable. See more about this in its documentation. The solution I guess is to get something like i18n_fields into core eventually.

OK, I understand now rszrama.
I agree, the ideal solution should be to get something like i18n_fields in core, so for the moment I'll use i18n_fields.

Thanks

For me all the field labels on the Prooduct Display Node got translated except for the ones where the field turns into a dropdown menu (like 'Size' at http://demo.commerceguys.com/dc/catalog/wearables/e-commerce-drupal). i18n_fields did not help. #10 did. This might be a separate issue though.

Yeah, it's most likely separate, a bug perhaps in i18n_fields. I'd check its queue to see if any particular field types still need support.

This likely means that we are missing a call to i18n_field somewhere. Most likely directly in the add-to-cart form.

Let's refocus this issue. Note that I haven't taken the time to reproduce this yet.

It's in commerce_cart.module lines 1522-1524. Could just be implemented incorrectly.

Confirmed the problem. Patch attached resolved the issue for us.

Hmmm but what about the situation with one non-english language site that doesn't need to have i18n module installed (or entity translation). In that case I just want to change that label but when I try to simply edit this field I get The field Price is locked and cannot be edited..

Installing i18n / entity translation module just to change that text seems kinda weird.

Tagging.

IMO #20 should be fine and is perfectly appropriate. Requiring i18n_field for translation of fields is fine.

Alrighty, committing #20. Thanks again, mr.baileys.

@zambrey - as for your situation, one solution would be to install in your language of choice with Commerce translation files for that language. Then when the field first gets created, it should have the proper label for your language. Not being able to change the label for locked fields is another general problem in Drupal core with respect to the fields system. What it really amounts to is core needing to differentiate between locked fields that just a) can't be deleted but can be modified and b) can't be deleted or modified. Right now, core only supports b, so we'll have to depend on i18n_field even for the translation of these field labels if you install in a language other than the one you want to finally use.

Wait a minute. We need a module_exists() wrapper around this.

Don't mind me.

@rszrama - thanks for your clarification. I thought that core has something to do with it.

Installing from scratch is not an option for me as I have almost everything prepared for launch. I found that this configuration is saved in field_config_instance table but since it is stored as blob it's rather hard to change.
I really really really don't like the idea of installing i18n package so I guess I have to learn about manipulating blob data.

@Damien - lol, I did the exact same double take when I first saw the patch until I realized it was inside the existing check. : P

For everyone interested in changing label of price field:

$record = db_select('field_config_instance', 'inst')
  ->fields('inst')
  ->condition('field_name', 'commerce_price')
  ->execute()
  ->fetchObject();
$data = unserialize($record->data);
$data['label'] = 'Enter your label here';
db_update('field_config_instance')
  ->fields(array('data'=>serialize($data)))
  ->condition('id', $record->id)
  ->execute();

Also, i18n might not help if your native language is set as source in admin/config/regional/i18n/strings, then it takes the English string, and allows you to translate the English language string only.

So you need to change that as well.

@Ranko, #31, the time-honored way to do things in the default language is to make a dummy translation. For example, "English, altered" or something like that. It inherits all the default language's stuff and then you just fiddle with the few things remaining. Most people use stringoverrides for that these days, but the old way works fine, and would solve this.