Make "Add to cart" button text a display format setting (configurable at the field level by content type)

Hmm, it's not a bad idea, but I'm not sure it needs to be a setting like this. The problem we wanted to avoid in Commerce was the Ubercart method of having user-definable strings that were then hard to translate (particularly for multilingual sites). However, it should be easy enough for either 1) a custom module on the site to alter the text of the button or 2) a contrib module to add a UI for this and bake it into the settings form. Well, the first option is easy enough, the second option may or may not be feasible depending on how alterable the display formatter settings form is.

It might be possible to expose translatable field settings to i18n_fields. If it is not, this will not belong in Commerce core for the reasons exposed by Ryan.

I'm sorry, but I don't buy the i18n reasoning for avoiding doing this. You're already including a Product:Title and Product:Description by default in every content type, and those have got to be at least as hard to translate as the button text, since most sites will have fewer button text strings than product titles and descriptions. Am I wrong? I don't have a lot of i18n experience so I may be mistaken, but I do definitely have a need to customize the button text, and I'd rather not have to write a custom module or theme function to do it.

Don't mean to sound ungrateful. I'm sure the universe of Commerce is much larger than my own applications of it, and I appreciate all the hard work that's gone into making Commerce as flexible as possible.

Titles are translated by another module and body / description textareas are fields... translated also by the i18n_fields module. ; )

Not trying to make anyone buy anything... just describing the way translating fields and interface text in D7 works right now. Comment #1 should still apply as a solution afaik.

While agreeing with everything rszarama wrote, shoudn't this patch solve changable button text and it's i18n? Point beeing that if you run English only store, you could change 'Add to cart' to, say, 'Bag it' easily.

Would love this functionality. +1

+1

+1 Does anyone have a workaround for this?

Just found the solution... go to the translations interface in administration, search for "add to cart" and you will be able to translate this string.

#5: commerce-1147690.patch queued for re-testing.

XC1, your solution replaces the "add to cart" string site-wide, but this issue is about having a different string on each content type or product type.

here is a new patch, a little different from kotnik one, use the "Add to cart" text as default value in the definition of the formatter and without changing the arguments for the "commerce_cart_add_to_cart_form()"

i forgot about the Views Add to cart form. here is the new patch

it seems it works

Can't RTBC your own patches, but I have it open for review. ; )

Setting this back based on:

1. You can only wrap string literals in t(). This is invalid: t($line_item->data['context']['button_text'])
2. This only addresses the use case of renaming the button for forms generated by the Views field handler for Add to Cart forms. It doesn't actually address this issue's request, which was to address it through the display formatter settings on a per-content type basis.
   

1. any thought/ideea how the multilingual should/could be done for a field formatter setting to be used in the formatter view?
2. patch from #13 but with the right multilingual approach

Basically, I don't know of any way to have multilingual variables stored inside a field display formatter settings array. It may be something we can work out through the Variable module or some other custom system, but honestly, it's already a solved issue if a site just uses the existing translation modules to translate "Add to Cart" into whatever they want. Then it's multilingual and translated everywhere it gets displayed.

For single language sites, we can basically just put it an override that lets people change the label but mitigates multilingual usage. This is what we do with the default checkout completion message.

Following. But really I'm looking for a simple, non-development programmer, way to change my single-language (English) Commerce store to say "Hire it!" instead of "Add to Cart" for self-explanatory reasons. Least I presume that's self-explanatory. I have looked but can't find any other thread that addresses this simple but surely common need.

Ryan/guys: Please. Put me out of my misery! *fake scream*

Q

We have a need for this too. We're going to investigate selling pre-order items that you can checkout and pay for, but the payment is delayed until the item "ships" (or in the case of digital items, is released). It makes more sense to make the Add to Cart button read "Pre-order" in this case.

I tried doing something similar in Ubercart with the Checkout feature (renaming it to "Secure Checkout" for UX purposes) but then found out that Drupal uses the button text as its $op, which then is checked. In UC's case it checks to see if the $op == 'Checkout' and if affirmative, brings the user to the checkout process. Obviously, not ideal.

If no one else gets to this I may have to hack at it, but I'm not sure when that will be. :)

'Add to cart' is a term used in North America. In the UK (another English-speaking country) it's generally 'Add to basket' (look at Amazon.co.uk). However, there are many other use cases for Commerce (eg, event registration and payment) where other text could be more applicable.

Either this should be a simple text field stored in the central store configuration, or something set in the Product Type. An option in Product Type would add more flexibility.

Or is there a simple way to theme this value?

Translate it using String Overrides or any other approach. The reasons it isn't simply configurable are covered above (and elsewhere).

@torgos - no $op used in here, so you should be straight. : )

Awesome, thanks Ryan! :)

Just to clarify: can we simply override/theme the display with, say, a form_alter? I would rather not rely on string override / translation / etc. (I'm only now starting to dive in, focusing on our Migrate stuff first.)

Thanks!

What a difference a day makes...

I used the following statement in settings.php (assuming English only site):

$conf['locale_custom_strings_en'][''] = array(
  '%title added to <a href="!cart-url">your cart</a>.' => '%title added to your <a href="!cart-url">basket</a>.',
  '%title could not be added to your cart.' => '%title could not be added to your basket.',
  '%title removed from your cart.' => '%title removed from your basket.',
  'Shopping cart' => 'Basket',
  'Update cart' => 'Update basket',
  'Your shopping cart has been updated.' => 'Your basket has been updated.',
  'Your shopping cart is empty.' => 'Your basket is empty.',
  'Shopping cart contents' => 'Basket contents',
  'View cart' => 'View basket',
  'Add to cart' => 'Add to basket',
  'Continue to next step' => 'Next',
);

Think that covered the basics. Seems to work fine

Yeah, you can use a form alter as expected.

Also, great work, arrrgh - I didn't know you could do that either. : )

@ rszrama: I tried Strings Override earlier and it didn't make any difference. I cleared caches and rebuilt permissions too. Should String Override definitely work here, i.e. have/anyone used it successfully on Add to Cart?

@ arrrgh: thanks too. Being a designer I try to avoid code overwrites too much. They always seem to bite me in the bum later! But I'll try that if Strings Override won't.

commerce_custom_line_items solves this by making editable line items and storing the value for the button text in the db.
Can commerce core take a similar approach?
Seems like it would be useful to have "product" line item be editable anyway.

That approach is not sufficient for multilingual sites, which has been the primary hangup thus far.

here is a patch with new approach
1. new field instance setting for custom text : 'Add to cart button text'
2. translation available with i18n_field translation.

i think this could done also in the display formatters (view modes), but it will require same work on i18_field to let us translate fields display data.

i think i forgot something

@arrrgh Thanks very much for your helpful tip about the settings.php file. Made for a quick solution.

Still looking forward to a solution to the original suggestion, it sounds like a good idea (custom "Add to cart" text on a per product-type/content-type basis).

Adding my vote for the ability to change the "Add to cart" button text based upon product variant. I'm building a school site right now that needs both "register" for classes as well as "add to cart" for selling physical goods.

I tested #32 with no success... the new field instance settings is correctly displayed and stored, but nothing has changed in my cart display...

Ok I solved my problem, there is an incompatibility with the stock module... which validate if the "add to cart" button should be enabled or not, and override its value.
Here is how I solved it in commerce_stock module :

function commerce_stock_cart_state_validate($form_id, &$form, &$form_state) {

  $product_id = $form['product_id']['#value'];
  $product = commerce_product_load($product_id);
  $qty_ordered = commerce_stock_check_cart_product_level($product_id);
  
  $line_item = $form_state['line_item'];
  
  $cart_button_text = isset($line_item->field_instance['add_to_cart_button_text']) ? $line_item->field_instance['add_to_cart_button_text'] : t('Add to cart');
  if (module_exists('i18n_field') && isset($line_item->field_instance['add_to_cart_button_text'])) {
    $cart_button_text = i18n_field_translate_property($line_item->field_instance, 'add_to_cart_button_text');
  }

  // Initialize the form
  $form['submit']['#value'] = $cart_button_text;
  $form['submit']['#disabled'] = FALSE;
  $form['#attributes']['class']['stock'] = 'in-stock';

I also want different text to replace 'Add to cart' for different product type.

Who ever looking to replace just 'Add to cart' for all the product type can use this module - String Overrides

Patch in #32 works great for me. Is it fair to say RTBC? Thanks @vasike.

Looks like an issue would have to be created for the commerce_stock module once this is committed to make the change mentioned in #36 that @camdarley mentioned.

Using this in production on 2 sites now. It would be really nice to have it committed so I don't make the mistake of updating the module without this patch...

Thanks!

#5: commerce-1147690.patch queued for re-testing.

I'm using the patch in #32, seems to work fine. As stated by deggertsen. Thanks @vasike for this great patch.
Also wondering if this is going to be committed any-time soon. If not how can I turn this patch into a separate module so that I can update without fear of losing the functionality this patch offers? Is this at all possible?

Any help, thoughts on this are welcome.

Hoping to get a maintainer's attention on this. Again, the patch works and should be committed or put into a separate module. Need a maintainer's guidance on this. Seems like this should be part of the core project as there are enough people wanting to change the default "Add to Cart" without having to deal with overrides.

Patch re-rolled to apply to most recent dev.

Saw this reroll not long before preparing the 1.9 release but couldn't get to it. Feature requests are really just of normal priority, so I'm reducing that, but I do promise to get a review in prior to the 1.10 release (which shouldn't take near as long as the jump from 1.8 to 1.9).

Thanks rszrama. I understand that it should only be normal priority, just trying to make sure that this isn't overlooked... Thanks for reviewing! I'm looking forward to having this committed so I don't have to manually add it each time there's an update.

This patch is exactly what I'm looking for. Thanks to all!

My use-case. I'm NOT using Commerce Kickstart. I have a custom multilingual install of Commerce. I'm using i18n to translate my Product display content type; entity_translation and title to translate Products titles.

I've applied the patch successfully. In my Product display content type, I've set Add to cart button text to Pay now. Add to cart remains unchanged (defiant it seems).

Added the following function in a module to check if Pay now is there. And it is! See attached image.

/**
* Implements hook_form_FORMID_alter() to change the Add to Cart button text.
*/
function c3sq_extras_form_commerce_cart_add_to_cart_form_alter(&$form, &$form_state) {
  $line_item = $form_state['line_item'];
  $product = commerce_product_load($line_item->commerce_product[LANGUAGE_NONE][0]['product_id']);
  if ($product->type == 'product' || $product->type == 'membership') {
     drupal_set_message('The Submit value is: ' . $form['submit']['#value']);
  }
}

What is it I'm missing?

p.s. Tested this patch in a fresh Commerce Kickstart and it works. So I am missing something. Just need to figure what it is.

This patch breaks and has no effect when the Commerce Stock module is enabled. Lines 137 and 258 of commerce_stock.module re-initialize the Add to cart form. Lines 123-160 are printed below.

/**
 * Form validation handler for commerce_cart_add_to_cart_form().
 *
 * For products with options (product dropdown) checks if the add to cart form
 * should be enabled (in stock).
 *
 * @see commerce_cart_add_to_cart_form()
 */
function commerce_stock_cart_state_validate_options($form_id, &$form, &$form_state) {
  $product_id = $form['product_id']['#default_value'];
  $product = commerce_product_load($product_id);
  $qty_ordered = commerce_stock_check_cart_product_level($product_id);

  // Initialize the form.
  $form['submit']['#value'] = t('Add to cart');
  $form['submit']['#disabled'] = FALSE;
  $form['#attributes']['class']['stock'] = 'in-stock';

  // Set global form for stock actions.
  global $stock_cart_check_data;
  $stock_cart_check_data = array(
    'form' => &$form,
  );

  // Integration with rules_form_alter().
  if (module_exists('rules_form_alter')) {
    // make sure rules_form_alter actions work from the stock event.
    global $rules_form_alter_data;
    $rules_form_alter_data = array(
      'id'  => $form_id,
      'form' => &$form,
      'state' => &$form_state,
    );

  }
  // Invoke the stock check event.
  rules_invoke_event('commerce_stock_check_add_to_cart_form_state', $product, $qty_ordered, $form);
}

@bisonbleu. It seems to me like that would be a Commerce Stock issue, not a Commerce issue if this patch were applied. With the patch applied you would need to update Commerce Stock to work with this modification, not the other way around.

Thanks @deggertsen . That's what I thought but I wasn't sure. I'll post to the the commerce_stock issue queue and report back.

Added the reference to the commerce_stock issue.

Thanks to @bisonbleu we have a patch for supporting this change in the latest dev version of commerce_stock.

Hmm, so I'm reviewing this pretty late before the Commerce 1.10 release unfortunately. However, looking at the implementation, I see that you've made the button text part of the field instance settings instead of the display format settings. This means that while it's configurable per product reference field, it isn't actually in the right spot - it isn't a given that every product reference field will be rendered as an Add to Cart form.

That said, perhaps it simply isn't possible to translate display formatter settings in the same way it is instance settings. If that's the case, I don't have a problem with the option remaining on the field instance - however, we typically include options required to rebuild the Add to Cart form in the line item passed to commerce_cart_add_to_cart_form() instead of including logic directly in the form builder function like the code in this patch that determines the appropriate Add to Cart button text value to use.

What are your thoughts, deggertsen?

@rszrama good thoughts. It probably would be better if this was part of the display format settings. I don't understand it all nearly as well as you do though so I'm not sure if in the end it would be better to leave it as is or move it to the display format settings. It would probably be better to move it, but for me this would be a fairly lofty task as I haven't had to do much with display format settings yet so I would need to learn how to mess with those first.

What's most important for me is that this patch works and I feel like this functionality is quite important, though I am surprised it hasn't had more attention. I guess people just use theme overrides or something... If that is the case and the alternative means for accomplishing this goal is satisfactory, perhaps it would be best to do what you suggest with this patch and make sure it is more perfected before it is committed. My only problem with that is what I suggested above in my lack of knowledge on what exactly to do. This is where your vast experience and help is very useful and needed. Perhaps you could at least outline what needs to happen before this can be committed and we can go from there?

I've been following this thread for a while and based on Ryan's comments in #54 I decided to take a crack at it. I've been dealing with field formatters for a little while now as I've been investigating alternative methods to rendering product reference fields and the like. (I also had to create a new widget for AmazonS3 to be able to autocomplete filenames from a cache table..)

Anyway, here's my first stab at a patch that adds $line_item->data['context']['button_text'] and uses that as the Add to Cart text if available. It's part of the $settings form in Display settings for a given content type, and I've also included it as part of the $options array in the Views handler commerce_cart_handler_field_add_to_cart_form.

I'm pretty sure this is what Ryan is looking for. (Note: I didn't include any translation aspect because I'm not as familiar there, and I'm not sure it's necessary with this method, but I am open to guidance on this aspect.)

Here's what it looks like on my dev site (please excuse the terrible layout):

I just realized I forgot to do a check_plain() in a couple of spots, which could open up vulnerabilities within the settings forms. This new patch fixes those spots, and so I've removed the additional (and now redundant) check_plain() call from the form element itself. This way all of the check_plain() happens at the $line_item->data level.

@torgosPizza - Awesome, this is exactly what I was thinking. Unfortunately, I ran up against a security release window and had to roll the 1.10 release before I could work on the patch any further. : (

The only thing missing is translatability. I got hung up trying to determine what it would actually take to translate the Add to Cart button text via i18n, and I think the gist is we just won't be able to use i18n_object translation as deggertsen's patch was. I don't see any way for i18n to translate nested properties on an object. I think we can take advantage of general i18n_string translation, though - I just didn't have enough time before the security team needed me to act.

Definitely happy to finish this up ASAP, though. Thanks for moving it forward guys. : )

@torgosPizza You're amazing as usual. Maybe one day I can hope to be as amazing as you. I'll work on testing your patch soon so that we can hopefully get this committed for the next release. Sad it didn't make it into this one, but at least it's getting attention!

@rszrama I hope you'll keep a close eye on this so that we can get it committed far before your next deadline =). One thing that is unclear to me about your comments is whether you are saying that my patch above is not able to use i18n translation or if you were saying that torgosPizza's patch can't. It looks to me like torgosPizza allows for translation, but maybe I'm missing something? I'm not familiar with i18n translation.

@deggertson: Haha, thanks. I'm not that amazing, but I am trying to learn as much as I can about D7. In the past couple of years as we've been working on our D6->7 upgrade I have peeked into pretty much every system that exists within.

Here's my first, I-don't-know-what-I'm-doing stab at a patch that has i18n support. I discovered that there is a function commerce_i18n_string() which is used in a couple of locations for Checkout help messages and something else. I'm not sure if what I've got here would work - I for some reason cannot figure out the Internationalization module, and am not sure how to get the translation settings up... so this is kind of a total shot in the dark for me. Would love guidance on if this is at all correct - the documentation is not all that helpful.

(I also looked at using i18n_field but that seems to only work on properties, which goes back to what Ryan was saying.)

Initial tests are unsuccessful with both #57 and #60. I am able to enter my alternate text in the display formatting options, but the custom text doesn't come up on the button... Not sure why as the patch appears to be sound. Perhaps it's a caching issue. I will try on another site to see if it's a fluke.

Yeah, you may need to clear your caches, since cart forms get cached quite a bit.

I've flushed caches a few times, but nothing is changing. I've tried on two different sites. I'll try to spend more time looking into it...

Are your pages created by Views? Keep in mind the Views "Add to cart form" has its own formatting preferences that are separate from just plain old formatters in the content type.

But, I'll see if I can reproduce the issue with the latest patch. Perhaps something got overlooked.

Found the problem. Line 62 of the patch you left out an "!" in front of empty.
So this:
$line_item->data['context']['button_text'] = empty($settings['button_text']) ? check_plain($settings['button_text']) : t('Add to cart');
Should be this:
$line_item->data['context']['button_text'] = !empty($settings['button_text']) ? check_plain($settings['button_text']) : t('Add to cart');

Once I fixed that it worked as expected!

Nice catch! Let me rewrite the patch and upload a new one for testing. (Just to be safe.)

Here is a patch with the fix from #65. Please test and review.

Also, @deggertson - were you able to test the i18n integration? I have no idea if what I did is the correct approach. Hopefully someone with more experience in this realm can test or rewrite the part of this patch that integrates with i18n.

Thanks for your help and nice work in finding my lazy typo. :)

Forgot to set back to Needs review.

I did not test the i18n integration (though I did use that patch). I have never used i18n so I would prefer to not be the one to test that part...

Ha, okay sorry. For some reason I'd thought you were using it in your implementation. Never mind!

-Double post

unfortunatelly still no solution for i18n integration.
So we need a translatable string for a field instance for a specific entity "view mode" (display).

i think we need to make new field string translation definitions for the commerce_product fields
something similar as for "default value" and "allowed values"
There is the API Documentation : http://cgit.drupalcode.org/i18n/tree/i18n_field/i18n_field.api.php?h=7.x...

And the example could be in i18n_field module
http://cgit.drupalcode.org/i18n/tree/i18n_field/i18n_field.i18n.inc?h=7....
http://cgit.drupalcode.org/i18n/tree/i18n_field/i18n_field.module?h=7.x-1.x

it seems very complex to build a new i18n translation for the field formatter properties.
or simply i didn't get it.

However i managed to do a integration for this text for the field instance translation, defining new translatable strings for these formatter display settings (button_text) for every view mode.

It will not work in Views if the product reference field is used with "Add to cart form" formatter.
There maybe is better to have rendered entities than fields with custom displays (view modes).

Are we ok with this or there is a better way to do the i18n integration?

p.s. : imho, it should at least commited the solution without translation. i imagine a lot of ecommerce sites with no multilingual or without no customisations needed for this button (default 'Add to cart' localized).

new patch : fixing the testing failing notice (i hope).

I agree with vasike. Unless someone who wants to step up and perfect the i18n integration, patch #75 should suffice.

I was wondering if in patch #75 could also be possible including the option of removing the cart button and quantity by content type or product type.

Perhaps adding some code from https://drupalcommerce.org/questions/20019/need-remove-add-cart-button-a... could help.

Many thanks

Can we just get #75 committed or make it a separate module or something? This issue has been here for 4 years and #75 seems like a perfectly good solution. i18n can be added later with a separate patch in a separate issue.

@andrews501, I'm pretty sure what you're asking should be a separate issue. We're having a hard enough time getting this simple functionality added...

The patch in #75 does exactly what it should on my site, and provides exactly the functionality that I would have expected to be there from the start. Would be nice to see it committed so I don't have to remember to re-apply the patch with the next release of Commerce :)

I agree the feature change in #77 should be raised as a separate issue. In terms of removing the Quantity from the Add to Cart form, you could this by creating different panel variants with different selection rules for the product display node. When you add the variation field for the product display as a pane in the variant, you can specify whether you want to show the quantity.

I suggest we add #77 as a new feature request, referencing this issue (perhaps as its parent issue).

I sent an email to Ryan (@rszrama) and have asked him to take another look. I know he was stuck on the translation issue, but hopefully this is resolved with @vasike's approach.

Thanks everyone!

I'd prefer to commit this w/ i18n support already if possible; we should have examples from other parts of this API to follow, no?

Tagging for http://contribkanban.com/#/board/commerce.

wow guys, great work here, even works with views if you want a view with a custom add to cart button, this opens up so much that you can do with commerce now, my use case was having one product that was a monthly sub and a yearly sub, 2 buttons, different text :)

Thanks again to all who contributed and can't wait for this to be committed :)

Just one small update.

when chaning the text on a button, I tried doing a special character ">" and it escaped it as HTML, then because it is being displayed as plain text, the HTML came up as just HTML.

Example:

Input special char

Get this result

Just thought if no one has caught it yet it can be fixed when committing :) if i knew how to re-roll the patch i would :(

I know the culprit is this little line (98 in commerce_cart_handler_field_add_to_cart_form.inc)

$line_item->data['context']['button_text'] = check_plain($this->options['button_text']);

The check plain is forcing html into the field :)

Setting back to Needs work.

Hi,

it would be nice to not only customize the text but also use HTML inside the add to cart button.
In that case I would use Font Awesome for example and add something like <i class="fa fa-cart-plus"></i> inside the add-to-cart button to display a cart symbol instead of text.

Not a bad idea @maxplus. I think it would be pretty easy to make that change in the patch.

I agree with @maxplus! Icons!

Wow guys. Just read the whole thread since my last (unhelpful) contribution 3 years ago. Got super-excited all the way to the bottom before wandering if this update is in the latest Commerce dev release - and stable enough to use on production sites, if so?

My latest use case scenario is that a client site needs to mix in new products that can be bought now (and as we're in the UK it needs to something else, almost anything else, other than 'Add to Cart') together with other items that need to be quoted for (which is how the site currently runs) where the default 'Add to Cart' text is altered via the stringsoverride module to 'Add to Quote'.

Unless I'm more stupid than I thought I can't see any other standard way to do this - and this patch/solution would be God-send.

Q.

@quantos I'm currently using the patch in #75 on a few production sites. It works great!

From my understanding here is what still needs to happen before it can be committed:

1. i18n translation integration
2. Allow for HTML and special characters in the "Add to Cart" button text.

I've updated the issue summary so that it's clear what these remaining "to do" items are.

I've addressed the issue of HTML special characters being allowed in the "Add to Cart" button text.
Allowing HTML tags in the button text is beyond the scope of this change.

The i18n translation integration is already included, unless I'm missing something:

1. The button text is translated through calls to commerce_i18n_object() in the
   field formatter and the hook_field_attach_view_alter() implementation
2. The translatable strings are listed in commerce_cart_i18n_string_list_field_alter().

What more would be needed for i18n translation integration?

Updating issue summary using the Issue Summary Template.
Recording Remaining tasks to reflect latest patch for review.

Patch from #90 works great!

#90 looks appropriate and ready to be committed.

@anneeasterling It appears—unless I'm missing something!—that the current model is in keeping with the current (7.x-1.x) Drupal Commerce architecture, as Product Display content types are intended to control how how products are displayed to the user.

A quick fix might be to use the patch in #90, and then to clone our current Product Display content type into a new Product Display type per the custom add-to-cart text we might want to use; then use something like Node Convert to move the desired Product Display nodes over into the new Product Display type... Thoughts?

Hello - It would appear that the i18n aspects of this might still not be 100%. I have I was having an issue with translating the add to cart text in a view once it was set to something other than the default. I found that the following code needs to be updated.

+      $button_text = !empty($line_item->data['context']['button_text']) ? $line_item->data['context']['button_text'] : t('Add to cart');
       $form['submit'] = array(
         '#type' => 'submit',
-        '#value' => t('Add to cart'),
+        '#value' => $button_text,
         '#weight' => 50,
       );
     }

The value should still be in a t function.

+      $button_text = !empty($line_item->data['context']['button_text']) ? $line_item->data['context']['button_text'] : t('Add to cart');
       $form['submit'] = array(
         '#type' => 'submit',
-        '#value' => t('Add to cart'),
+        '#value' => t($button_text),
         '#weight' => 50,
       );
     }

I will post a patch in the morning, if time permits.

@johnpicozzi #97:

The t() function should not be passed a variable, as per the API documentation. But it should be easy enough to use t() correctly in this scenario; for your patch, I'd suggest following the example in the docs of using a helper function for the purpose of formatting the text.

@torgosPizza - Thanks for keeping me honest!

After some digging it doesn't look like the t function & variables are used in this manner other than using the Variable Translation module. Before re-rolling the patch I wanted to get an opinion on the following code change using the locale function.

else {
      // if we have a custom button value, attempt to translate it, after filtering it.
      if (!empty($line_item->data['context']['button_text'])) {
        $button_text = function_exists('locale') ? locale(filter_xss($line_item->data['context']['button_text'])) :
          filter_xss($line_item->data['context']['button_text']);
      } else {
        $button_text = t('Add to cart');
      }

      $form['submit'] = array(
        '#type' => 'submit',
        '#value' => $button_text,
        '#weight' => 50,
      );
    }

Updated the patch from #90 with my fix above. Will be more than happy to adjust if this isn't the best approach. Just wanted to get a fix out, in case someone else runs into this problem.

Same patch as above, but updated for most recent dev.

This has been a long time coming and the translation stuff looks good to me. According to @rszrama in #58, translatability was the only thing missing so I believe this is now finally ready to be committed!?

All that's left is some tests to be written. Updated the summary to reflect i18n integration has been functionally tested now.

Patch in #101 applied cleanly for me on Commerce 7.x-1.13+38-dev, and I was able to update button text.

Many thanks!

I've been googling for an hour and I cannot find whether what is the current preferred method of doing this. Was the patch applied and where is the current setting to change the button. The original post specifies some suggestions, but I do not see a field. Neither does the drupal commerce website answer this question.

Maybe I need a fresh look, but if anyone can tell me where to change the button text, that would rock.

Thank you!

@Paintbox. This patch has not been applied as stated in #102 and in the issue summary it is pending automated tests to be written. Once someone steps up and writes those tests then we should be able to get one of the maintainers to commit the patch. Until then the patch must still be manually applied if you would like this functionality.

Tested on Commerce cart Version: 7.x-1.14, by applying the patch by hand.

Added a custom text for the button in a view. The button text showed up in the "Translate interface", with path /admin/structure/views/view/[view_id]/preview/entity_view_1/ajax

New text showed up nicely on add to cart buttons.

Anyway, did not tested the translation, as we have only English language in our site at the moment.

Need this feature too. Currently having donations, products and events on the same store. We will need the label to be DONATE, ADD TO CART, REGISTER respectively.

I can confirm that translation is working for the button text for both product display and view fields.

However, in the issue description, it says:

The custom button text string can contain HTML entities but cannot contain HTML tags.

I've found that the current patch still doesn't work for html entities. I could not use & or > or any other html entity I tried. Instead, & or > (or other) displayed on the button.

So, this patch either needs more work or we should just proceed with the limitation that html entities can't be included in the button text.

Works as designed.

Thanks for the work everyone! (For reference, I confirmed with Lisa in Slack that string filtering not allowing HTML entities is expected.) Made some minor comment / code style changes and committed. \o/

Wonderful news! Thank you rszrama!