Translate confirmation email

Are you sure you're running latest Commerce?

Commerce 2.12 had email translation fixes, and introduced tests that confirm that translation works.

I tried to reproduce this but could not. I was using the development_environment module to look at sent emails on my localhost.

1. I enabled the Hungarian language.
2. Clicked 'Resend receipt' for an order in the admin orders list to make email texts appear at admin/config/regional/translate.
3. Translated 'Order #@number confirmed' to Hungarian at admin/config/regional/translate.
4. Went back to the orders list and sent the receipt again. The email subject was translated correctly.
5. Removed English from the languages list (since you mentioned that your site is in one language only) and tried it that way too, but the subject is still translated.

Are you able to reproduce this on a clean commerce install too?

First I also faced the problem but then re-checked my preferred language setting for my admin account and it was English. As soon as I corrected it and set it to Hungarian my email also arrived with the translated strings. :)

I'm having this problem as well on a multilingual site. The receipt email contains mixed strings, because some strings follow the user language setting and other strings follow the user interface language setting. So if the user preferred language is set to English, but the user interface language is set to Swedish using the language switcher, then the email will contain both English and Swedish strings.

This may not be a big problem if you require users to register and set a preferred language, but we're allowing guest orders which get set to the site default language. The receipt email will then contain mixed language strings if the customer uses some other interface language than the default site language.

Confirming that issue is still there. Drupal Commerce 8.x-2.20, Drupal 8.9.1. Site has English and German languages enabled. I set German to be default. When I go trough checkout on German email I get is mostly on English and only some small parts are translated to German ("Shipping" and tax names only). Strings that are added to template file with |t twig filter can not be found on User interface translation page.

Landing page (after returning from off site payment) is in correct language.

Solution @pixelrainbow suggested didn't help. That is, it doesn't effect language for other people. Didn't test how it works for admin it self, since that wouldn't be much useful.

An update: found out that translations are not working even in template that provides wrapper content for that content. I'm using Swift Mailer and content inside swiftmailer.html.twig also is not translated, but always displayed on English. I'm not sure any more is it issue of Commerce module or something more general.

Some workaroung I'm using - setting languge variable from hook:

function hook_preprocess_commerce_order_receipt(&$variables)
{
  $variables['language'] = \Drupal::languageManager()->getCurrentLanguage()->getId();
}

and inside template file:

{% if language == 'en' %}
              Thank you for your order!
{% else %}
              Vielen Dank für deine Bestellung!
{% endif %}

For authenticated customers, we're using their preferred language which seems to be the right thing to do.

In case the customer isn't authenticated, the commerce mail handler is going to use the current language as the langcode.

If you need any of this to work differently, you're free to either swap the order receipt service, or the commerce mail handler to always force the language used to a particular one.

The receipt mail can be sent by an admin too in which case we really don't have a better choice than using the customer's preferred language.

However if the customer goes through the checkout process in a given language I think it's safest to send the receipt in that language. The customer might not even be aware they can set a preferred language. (On some sites they can't even set their preferred language, it's just set to whatever the current language was during registration.)

Attached patch checks if the customer is the current user and if so, uses the current language for the receipt mail. I can add a test if needed.

One related problem is that the preferred langcode is not set correctly when you register in the login pane. You might think that happens automatically as a default value but sadly, that is not the case.

The patch in #14 works around that by ignoring that value for the initial checkout mail, but if you later on want to use it for something else, or send out additional mails for the order (shipping confirmation or something) then you're back to the original problem.

As a lazy (because no DI) quickfix, I'm adding the same logic that accountForm has to initialize it to the current interface language when you register during checkout. We'd actually like to make it configurable there as well, but that's a bigger change that might need settings and stuff. I very long time ago I also proposed some factoring of that pane to make it easier to customize the form and most importantly, the, the created user account, that would also be nice still, even though it has been improved for configurable fields since then.

I suppose that could also be done on its own, as the other change could be seen as controversial while this I think this is a straight-forward bugfix.

Turns out there is another recent issue reporting the same: #3201009: Checkout user registration language, so you can ignore that interdiff and then this can discuss whether or not we should ignore it.

Could we get a patch that doesn't contain logic for #3201009: Checkout user registration language? Since this got in?

That's #14 then. Note that I'm not 100% sure that this is really a desired change, it definitely is more controversial than that I think. You could end up sending the initial mail in language A but then follow-up mails later on would still be in language B if the language was not set "correct" on the user. I don't think we store the order/checkout language anywhere, if we do then we could use that instead but it's all a bit questionable :)

On the other hand, quite a few sites might not expose the setting at all and then users don't have a chance to correct it. But the behavior is the same for any user mails like password recovery that are sent to the user.

#2603482: Clarify order language behavior was the original issue attempting to solve this (by storing order language in a field and using it for all emails).

In my opinion language works fine in receipts.
Perhaps some users just don't intuitively see all the possibilities.

The way it works for me:
Customer's set site language defines the receipt's translation during purchase => send receipt.

Customer's set site language defines the [resend] button used by those on the admin's side.

Now, for those who want even more flexibility. There's always the language variable.

Just put:

function baoplate_preprocess_commerce_order_receipt(&$variables) {
  $language_id = \Drupal::languageManager()->getCurrentLanguage()->getId();
  $variables['language_id'] = $language_id;
}

in the your_theme.theme (and also on the admin side theme).

and then in the TWIG use something like this (and also on the admin side theme):

{% apply spaceless %}
              {% if language_id == 'zh-hans' %} // your desired language code
                {{ '公司名称' }}
              {% else %}
                {{ 'company name' }}
              {% endif %}
                  {% endapply %}

with or without the spaceless filter, depending on preference.

Using the code above both admin or user can switch to any language they want using language switcher and get the desired translation, overriding the user's site language choice and instead using the current language choice.

So this is just my 5 cents, that I don't believe there's any issues with how things work with receipt language in commerce-8.x-2.25.

I think the actual problem mentioned in the issue summary (the subject of the mail not being translated correctly) is because when the title is defined it is not passing the language in \Drupal\commerce_order\Mail\OrderReceiptMail::send():

    // Provide a default value if the subject line was blank.
    if (empty($subject)) {
      $subject = $this->t('Order #@number confirmed', ['@number' => $order->getOrderNumber()]);
    }

This falls back to the interface language of the currently logged in user, or the site's default language.

We should pass the langcode we determined as an option here, e.g.

    // Provide a default value if the subject line was blank.
    if (empty($subject)) {
      $subject = $this->t('Order #@number confirmed', ['@number' => $order->getOrderNumber()], ['langcode' => $langcode]);
    }