Product variation not translated on "add to cart" form

We also need a test for this. We have no i18n testing

Added the suggested code.

+++ b/modules/cart/src/Form/AddToCartForm.php
@@ -179,6 +179,11 @@ class AddToCartForm extends ContentEntityForm {
+    $language = \Drupal::languageManager()->getCurrentLanguage(LanguageInterface::TYPE_INTERFACE)->getId();

We'll want to properly inject this. And make a PR on GitHub so we can run tests, at least.

We could run i18n test as a follow up, since there's no existing structure for that.

There is a new PR about translations (multilingual) on Add to cart form
https://github.com/drupalcommerce/commerce/pull/682

What's there
- new CommerceContentEntityBase to be used to get translations of the referenced entities
- Update product and product variations to use this
- Update also the Order item to use this for purchased entities
- Update product variation to get translated values for the Attributes
- Make sure the Ajax loads the translated product variation.
- Add language to addToCartForm code available in a previous PR
https://github.com/drupalcommerce/commerce/pull/681

@todo : tests & tests of course

PR updated with tests AddToCartMultilingualTest - 2 Tests available for the 2 widgets available:
- testProductVariationAttributesWidget
- testProductVariationTitleWidget

PR green now.

Closed as duplicate

PR "reroll"

Hi
I am having a problem translating product variations to the Arabic language.
Please see attached picture.

I create the product in English language then hit the translate button. Everything is translatable except some parts of the 'variations' section.
For example, 'Title', 'Active', 'Published'

Thanks for your help.

I added this patch in the AddToCartForm.php. Commerce 8.x-2.0-rc1
But, It's not working.

 public function submitForm(array &$form, FormStateInterface $form_state) {
    parent::submitForm($form, $form_state);

    /** @var \Drupal\commerce_order\Entity\OrderItemInterface $order_item */
    $order_item = $this->entity;
    /** @var \Drupal\commerce\PurchasableEntityInterface $purchased_entity */
    $purchased_entity = $order_item->getPurchasedEntity();
    
    $language = \Drupal::languageManager()->getCurrentLanguage(\Drupal\Core\Language\LanguageInterface::TYPE_INTERFACE)->getId();
    if($purchased_entity->hasTranslation($language)){
      $purchased_entity = $purchased_entity->getTranslation($language);
    }

    $order_type_id = $this->orderTypeResolver->resolve($order_item);
    $store = $this->selectStore($purchased_entity);
    $cart = $this->cartProvider->getCart($order_type_id, $store);
    if (!$cart) {
      $cart = $this->cartProvider->createCart($order_type_id, $store);
    }
    $this->cartManager->addOrderItem($cart, $order_item, $form_state->get(['settings', 'combine']));
    // Other submit handlers might need the cart ID.
    $form_state->set('cart_id', $cart->id());

    drupal_set_message($this->t('@entity added to @cart-link.', [
      '@entity' => $purchased_entity->label(),
      '@cart-link' => Link::createFromRoute($this->t('your cart', [], ['context' => 'cart link']), 'commerce_cart.page')->toString(),
    ]));
  }

I tried in same 8.x-2.x-dev. but, no luck.

Thanks in Advance

PR update - fix merge conflict

Attaching vasike's latest PR as a patch (don't trust revolving PR patches anymore :))

That patch did not apply. I merged 8.x-2.x into vasike's branch on https://github.com/drupalcommerce/commerce/pull/682

This patch applied.

We have heavily customized add to cart forms. This solves most normal use cases but does not handle \Drupal\commerce_product\ProductVariationStorage::loadEnabled

The way I fixed it was to add the following after executing the entity query, and before running the filter event.

    if ($product->isTranslatable()) {
      $langcode = $product->language()->getId();
      foreach ($enabled_variations as $index => $enabled_variation) {
        if (!$enabled_variation->hasTranslation($langcode)) {
          unset($enabled_variations[$index]);
        }
        else {
          $enabled_variations[$index] = $enabled_variation->getTranslation($langcode);
        }
      }
    }

Patch with fix added. However needs tests.

Found more

  /**
   * {@inheritdoc}
   */
  public function loadFromContext(ProductInterface $product) {
    $current_request = $this->requestStack->getCurrentRequest();
    if ($variation_id = $current_request->query->get('v')) {
      if (in_array($variation_id, $product->getVariationIds())) {
        /** @var \Drupal\commerce_product\Entity\ProductVariationInterface $variation */
        $variation = $this->load($variation_id);
        if ($variation->isActive() && $variation->access('view')) {
          return $variation;
        }
      }
    }
    return $product->getDefaultVariation();
  }

Does not support langcode.

Adding related issue.

This patch caused bug reported in #2915548: Attribute selection widget includes invalid variations when rendering form element.. Missed it in the diffs. New patch.

Should I go ahead and apply #21 or should I wait for more fixes?

I have been waiting for this patch for a long time.. :)
My website depends on it. I can not deploy without this patch..

Thanks

With patch #21 I'm seeing success on a customer site which we've hooked into Lingotek. However it is a custom add to cart form. But we also customized the cart page which re-uses the attributes widget. We're seeing good things end to end.

I still plan on adding the patch to a more typical 2.x install and reviewing.

But for all intents and purposes.. I think #21 can be considered "final draft" waiting for better review and more tests.

Confirming.
Patch #21 works ... Yay..
I am so happy..

Thanks Matt

We'll need to review every bit of code that loads an entity, and then see if a call to ->getTranslationFromContext() is needed. Core does it all over the place.

+    // Load Product for current language.
+    if ($product->isTranslatable() && $product->language()->getId() != $langcode && $product->hasTranslation($langcode)) {
+      $product = $product->getTranslation($langcode);
+    }

Aside from the fact that the middle condition is redundant, this is not how we should be loading translations.
We need $product = $this->entityRepository->getTranslationFromContext($product, $langcode);
That's what core uses everywhere, and what we should be using outside of entity classes. It does the usual thing, but also ensures language fallback.

+    if ($product->isTranslatable()) {
+      $langcode = $product->language()->getId();
+      foreach ($enabled_variations as $index => $enabled_variation) {
+        if (!$enabled_variation->hasTranslation($langcode)) {
+          unset($enabled_variations[$index]);
+        }
+        else {
+          $enabled_variations[$index] = $enabled_variation->getTranslation($langcode);
+        }
+      }
+    }

The core logic is to fallback to a different language when a translation is missing. Seems odd to introduce new behavior here ("Hide untranslated entities").

+    $product = $this->getTranslatedReferencedEntities('product_id');
+    return reset($product);

We could introduce a getTranslatedReferencedEntity() I guess?

+use Drupal\commerce_product\Entity\Product;
+use Drupal\Core\Entity\Entity\EntityFormDisplay;
+use Drupal\language\Entity\ConfigurableLanguage;
+use Drupal\Tests\commerce\FunctionalJavascript\JavascriptTestTrait;
+use Drupal\commerce_order\Entity\Order;
+use Drupal\commerce_product\Entity\ProductVariation;
+use Drupal\commerce_product\Entity\ProductVariationType;
+use Drupal\Tests\commerce_cart\Functional\CartBrowserTestBase;

It's a nitpick, but we should order these namespaces properly (alphabetically).

+  public function getTranslatedReferencedEntities($field_name) {
+    $refereced_entities = $this->get($field_name)->referencedEntities();

Typo in variable name.

+  /**
+   * Ensures that the provided entities are in the current entity's language if
+   * entity is translatable or current interface language otherwise.
+   *

Needs a single line description.

fixing spelling mistakes to make this issue more searchable

I applied the patch in #21. The patch successfully causes the label to be translated, but the values (in the select dropdown on the Add to Cart form) still do not appear to be translated.

Potential factor: My site has a default language of Japanese, and English is a translated language. (I have had problems in the past when code assumes English is the default language.)

The patch successfully causes the label to be translated, but the values (in the select dropdown on the Add to Cart form) still do not appear to be translated.

I have seen this problem, too. Where auto-generated titles are not re-generated for the language.

Latest patch. Adds some kernel testing to variation storage, which is where most of this all stems from. Pushed all to PR as well.

New patch. Kernel test is fixed. However the functional JavaScript test is broken

New patch attempt. Adds test coverage for variation title generation (with multilingual, too.)

Found out why the FunctionalJavascript tests may be failing. Even though the site's default language is set to FR, toUrl still uses the entities current language

    // Display links by default based on the current language.
    // Link relations that do not require an existing entity should not be
    // affected by this entity's language, however.
    if (!in_array($rel, ['collection', 'add-page', 'add-form'], TRUE)) {
      $options += ['language' => $this->language()];
    }

This should fix the tests now that toUrl is being used properly :)

Generating a translation before the product back reference is generated causes the translated label to go out of sync, when auto-generated. When in the UI this won't happen as a product and its variations will be created, then translated. This only occurs when using commerce_product_variation_title. Otherwise getOrderItemTitle always returns a generated title if there is not one set. Explaining why the first test always passed but second one failed (empty labels in select.)

Updated version. Removes some changes to a checkout test. Also use getTranslatedReferencedEntity when appropriate (order, order item)

@@ -152,8 +153,8 @@ class ProductVariationTitleWidget extends ProductVariationWidgetBase implements
    *   The selected variation.
    */
   protected function selectVariationFromUserInput(array $variations, array $user_input) {
-    $current_variation = NULL;
-    if (!empty($user_input['variation']) && $variations[$user_input['variation']]) {
+    $current_variation = reset($variations);
+    if (!empty($user_input) && !empty($user_input['variation']) && $variations[$user_input['variation']]) {
       $current_variation = $variations[$user_input['variation']];
     }

Changing the variation selection logic in a multilingual patch is making me super nervous. Looks like a bundled unrelated fix, on an already huge patch.

diff --git a/modules/product/src/ProductVariationStorage.php b/modules/product/src/ProductVariationStorage.php
index 538b5b23..fc830b2f 100644
--- a/modules/product/src/ProductVariationStorage.php
+++ b/modules/product/src/ProductVariationStorage.php

   /**
+   * The entity repository.
+   *
+   * @var \Drupal\Core\Entity\EntityRepositoryInterface
+   */
+  protected $entityRepository;

This is a big problem. We can't inject the entity repository into a storage. And we can't have some storage methods return translated entities (such as loadBySku()), while others return non-translated entities (loadMultiple(), etc).
Selecting a translation must live on a layer above the storage.

+        return $variation->getTranslation($this->language()->getId());
+      $attribute_value = $entity->getTranslation($this->language()->getId());

In both Product and ProductVariation we are manually doing getTranslation().
This is bad, we are not only duplicating logic with getTranslatedReferencedEntity(), but it's also not consistent, the helper methods do hasTranslation() and then getTranslation(), but here we only do getTranslation(). So in one case we get the original entity when no translation is found, in the other we get a newly created translation without any translated data.

Luckily we have $this->ensureTranslations(), and we can introduce $this->ensureTranslation() as well.

+  /**
+   * Gets the translations of an entity reference field.
+   *
+   * @param string $field_name
+   *   The entity reference field name.
+   *
+   * @return \Drupal\Core\Entity\ContentEntityInterface[]
+   *   The entities.
+   */
+
+  /**
+   * Gets the translation of an referenced entity.
+   *
+   * @param string $field_name
+   *   The entity reference field name.
+   *
+   * @return \Drupal\Core\Entity\ContentEntityInterface
+   *   The entity.
+   */
+  public function getTranslatedReferencedEntity($field_name);

These two methods do the same thing, but have different descriptions.

I suggest this:

  /**
   * Gets the given field's referenced entities in the current language.
   *
   * @param string $field_name
   *   The field name.
   *
   * @return \Drupal\Core\Entity\EntityInterface[]
   *   The entities.
   */
  public function getTranslatedReferencedEntities($field_name);

  /**
   * Gets the given field's referenced entity in the current language.
   *
   * @param string $field_name
   *   The field name.
   *
   * @return \Drupal\Core\Entity\EntityInterface
   *   The entity.
   */

I'm going to try and dissect this patch. For instance, I added two areas of test coverage which did not exist so that I could test the multilingual version of it. Those should be spun off in new issues.

Here is an updated patch built off of a few split-off issues. This is much more focused on the add to cart aspect. I'd like to review the variation storage issue outside of this one, however.

No idea what I did with the last patch. Apparently ".patch" is that much difference than ".diff".

#51 did not work for me ... i get a diff complaint in cli

Excuse me if this very obvious to you or if it is a newbie stuff but I think it may be very relevant to note it under this issue. And I hope I'm not hijacking.

Right now I can translate a paragraphs field attached to a product variation by checking the "Users may translate this field" option illegally. (Illegally, because they discourage to do so under field settings, see the attached image).

This was possible before the patch in #40 and after that it is still working very nicely.

Nowadays things are getting done with paragraphs module and I can't think of a product variation page without paragraphs. Since paragraphs module has its own way for translation settings and its field type is not entity reference but entity reference revisions, I thought it would be good to consider it while fixing this issue.

#51 did not work for me ... i get a diff complaint in cli

It requires -dev changes.

1. +++ b/modules/product/tests/src/Kernel/ProductVariationGeneratedTitleTest.php
   @@ -137,4 +137,58 @@ public function testTitleGenerated() {
   +  public function testMultilingualTitle() {
   

   This should be its own issue.

2. +++ b/modules/product/tests/src/Kernel/ProductVariationStorageMultilingualTest.php
   @@ -0,0 +1,186 @@
   +class ProductVariationStorageMultilingualTest extends CommerceKernelTestBase {
   

   This should be its own issue.

Per #2923158: Test that the variation storage works in a multilingual context we will not be adjusting the storage and need to ensure translations in the layer above, our add to cart forms and such.

Here is the latest patch against 2.x HEAD. Injected field translation is now fixed.

Fixup usages to ensure entity repository is used.

New patch which adds helpers than should ensure variations are in proper translations, which means attributes will be.

WOO! We are green. 27kb smaller patch thanks to child issues which provide better test coverage. Assigning to bojanz for review so we can commit this sucker.

I tested the patch in #61 but I'm still having the same problem I described in #29:

The patch successfully causes the label to be translated, but the values (in the select dropdown on the Add to Cart form) still do not appear to be translated.

I cleared the cache multiple times, went back and editing the product variation translation, and added a new product variation translation to test whether it was just the old strings not being refreshed. Although the translation shows up correctly in the admin UI (/admin/commerce/product-attributes/manage/MYTYPE/translate/en/edit), it still shows up in Japanese (default language) instead of English (UI language, and everything else is in English on the page).

Can you please specify what values in the dropdowns are not translated: Attributes or Variation Titles. We have two widgets. There is test coverage in this patch which asserts translated attribute titles.

Perhaps there are some flaws in our test through language negotiation. The tests change the site's default language. I guess this is an inappropriate approach.

@mglaman: I think they are attributes. The specific text from the UI that is not showing up as translated (even though it has already been translated in the UI) is the text at /admin/commerce/product-attributes/manage/MY_TYPE in the "Name" field under the "Value" collection that appears when you check the box "Enable attribute translation."

Yes, those are attributes.

Okay, I need to review our test coverage.

If it helps, this is some of my configuration for the form:

commerce_product.commerce_proudct_attribute.TYPE.yml

uuid: 4408d8d2
langcode: ja
status: true
dependencies: {  }
id: TYPE
label: 期間
elementType: select

core.entity_form_display.commerce_order_item.TYPE.add_to_cart.yml

uuid: 37cf13a2
langcode: ja
status: true
dependencies:
  config:
    - commerce_order.commerce_order_item_type.TYPE
    - core.entity_form_mode.commerce_order_item.add_to_cart
  module:
    - commerce_order
id: commerce_order_item.TYPE.add_to_cart
targetEntityType: commerce_order_item
bundle: TYPE
mode: add_to_cart
content:
  purchased_entity:
    type: commerce_product_variation_attributes
    weight: 0
    settings: {  }
    region: content
    third_party_settings: {  }
hidden:
  created: true
  quantity: true
  unit_price: true

Your site has Japanese as the primary language and English second, correct? Today might also be vital to proper testing

For my case, I don't see any change after the update!!
I have to go back and make sure commerce is updated properly,

I will let you know of my findings ,,

Just as a note. I've built a couple of multilingual commerce sites on Drupal 7.x and I remember from my experience that despite Drupal system allows to create a site with other than English primary language I'd not recommend anyone to do this if they don't want language issues appearing there and here.

As for me the best way is to translate a site to your own language from English.

@mglaman Yes, Japanese is the primary language and English is the second language.

@drugan I had the same experience in Drupal 7, but in Drupal 8, non-English language install is supported, and generally speaking I've had a lot less trouble using languages other than English as the default language.

I'm going to merge #61.

I am going to open the following follow-ups:

• Test Add to Cart with the variation title's widget
• Multilingual tests currently only work off of the default language and not testing via language negotiation

Seeing how latest merge with 8.x-2.x turns out.

https://travis-ci.org/drupalcommerce/commerce/builds/310260922

I guess generating patches from GitHub just explodes, now.

@mglaman After four hours of testing today, I accidentally found the cause of the bad behavior in #29 (values in the select dropdown on the Add to Cart form do not display as translated even though they have been translated in the UI).

The problem occurs if you have "Translation enabled" on the Product Variation Type page:
/admin/commerce/config/product-variation-types/default/edit

I mistakenly thought this was necessary to enable translation of product variations, but it is not-- this is just the translation for the product variation type itself, and if this is turned on, the add to cart form translation doesn't work.

The "fix" for me was as simple as turning this off.

@mglaman I applied patch and added product to cart. But the message is not translated. Please refer the attached image.

Thanks

My last patch forgot this method to ensure variations loaded from storage were translated.

  /**
   * Gets the enabled variations for the product.
   *
   * @param \Drupal\commerce_product\Entity\ProductInterface $product
   *   The product.
   *
   * @return \Drupal\commerce_product\Entity\ProductVariationInterface[]
   *   An array of variations.
   */
  protected function loadEnabledVariations(ProductInterface $product) {
    $langcode = $product->language()->getId();
    $variations = $this->variationStorage->loadEnabled($product);
    foreach ($variations as $key => $variation) {
      $variations[$key] = $this->entityRepository->getTranslationFromContext($variation, $langcode);
    }
    return $variations;
  }

An interesting follow up needs to be ptmkenny's comment in #79

Travis passed. DrupalCI passed. Adjusting credits for those who did manual review

Thank you, everyone! This has landed. Expect it in the 2.3 release slated for Jan 3rd.

i am using commerce 8.x-2.6 and this is still an issue.

Hi all, +1 for getting this released :-)

Update, it is included, I can see the patch code in my files already, but... the cart still shows the English name of the product. Can anyone tell me what I am doing wrong?

Yes I can confirm this is still an issue and a big one...

@oakulm
Responding to an issue closed 17 months ago is a good way to never receive help.
The fix for this bug was shipped in Commerce 2.3, 10 releases ago.
Unless you're running an even older version than that, your problem is a different one and requires its own issue.

Thank you for the reply especially as this is quite old issue... Status is set to closed but there are two comments before me stating the same problem is still there... And I'm running the lates versio of Commerce 2.. I probably have to create a new issue than :)

I can confirm that this problem still exists in Commerce 2.17.

same here...

In case anyone still finds this thread, the procedure to make variation translations work can be found here: https://www.drupal.org/project/commerce/issues/3247257#comment-14282039

Problems may occur if you have a product variation with an attributes. In that case you have to translate the product name first, and then add the product variation(s), and translate them. Otherwise the variation name won't display as translated (just the attributes), no matter that they appear so in the store. Translation options for the product type and variations have to be enabled. In Cart form (Order) view you have to filter the product variation based on the user Interface text language selected for page. Thus you have to have a relationship for the product variation too.
#95 is not a solution, besides that will erase all translations so far.

Also make sure that the default language has the language prefix defined. I fiddled around for hours because having a structure like

• domain.com (default language german > needs the /de/!)
• domain.com/en (english version)

still an issue for 2.28