Improve UX for translating product variations

Translating product variations worked fine a while back. While you translate the product the inline entity form widget translates the variations. This approach won't change in the near future.

We should add tests to confirm this works. I'll try to test manually soon.

It does not work when you save the product translation, it gives you an error (the product variation does not exist), and you have to remove the variation and create a new one, then it works, but you can't use that for automatic translations.

product variation titles do not translate. for example ... if you create a new language product for an existing english language product and you add some variations and translate the title then choose Product Variation Title at /admin/commerce/config/order-item-types/default/edit/form-display/add_to_cart you will see translation does not work. the product pages being viewed in another language show the correct language text everywhere else on the page except in the product variation drop down list which still shows English. i have checked my translation settings everywhere i can think of and this is the only place i am seeing a translation issue.

For me it would make sense to have price field translatable. Is there reason why it's not? It would be probably the easiest approach for multilingual-multicurrency store.

For #7, can you try -dev? There were some recent commits to fix variation label translation when generated, and tests added.

This should be fixed as of 2.3. We need someone to manually test and review this. I don't think we have automated tests for admin on this .

I have tested variations translation manually with latest .dev.

Generally... it works.

Some improvements would be nice though...

1.

When new product translation is added - variations are not translated automatically. We have to edit+update each variation to make variation translation to work.

I don't know if this is how variation translation is supposed to work, but it would be better if IEF would create variation translations automatically when new product translation is added.

2.

When new variation is added to product (original language) - it is not translated automatically to other languages. We have to edit+update this variation in each product translation language to make variation translation to work.

I don't know if this is how variation translation is supposed to work as well, but it would be better if variation added to product (in original language) would be translated automatically to all other languages.

-----

Both these automatic behaviors would be especially nice to have in case when variation type consists only of "easy-to-automatically-translate" fields like tiltle and product attributes (most cases).

If there is some kind of text description field in variation type (or any other field type which needs manual translation) - then such field would need additional manual translation actions as in cases listed above.

This is still a problem.Test on last commit of commerce with d8.6.
commit 51c0c5ef5dd161bd23d61966a1c8309b7899c807 (HEAD, origin/8.x-2.x)
Author: thejacer87
Date: Wed Apr 25 14:54:02 2018 +0200

Issue #2965917 by thejacer87: Update Latvia VAT taxes

During my development and testing, I found this is not a UX problem at all, (and otherwise I'd strive to write accurate docs at this time). The functionality for translating product variations is broken, and this is a major bug. Additionally, in order to close this issue, functional tests must accurately be written as well.

To further clarify, with a clean install of Drupal 9.2.9 and Commerce Core 8.x-2.28, *unless* the stakeholders are willing to accept a unique SKU for the same Product in multiple languages, it is not possible to translate Product Variations.

Creating unique SKUs for each translation of a single Product places an unrealistic burden upon something like a small restaurant with a tourist restaurant menu in multiple languages. If the restaurant has been in business for ages and their menu is already in 6 languages, they'll need 6x new SKUs imposed upon them just to use the current Drupal Commerce, and that's too much cost and complexity to have to accept.

That report of focused testing follows earlier development attempts with Commerce and Droopler, and for whatever reason, I wasn't given such a clear error message then, and it certainly wasn't easy for me to pinpoint at what point the system broke, until I tested everything cleanly. In fact at that earlier point, I was able to create identical SKUs while being given no warning, and failing expected functionality.

On Commerce 8.2.x and Drupal 9.3.x a user can't translate product variations with the 'Translate [product variation] product' permission. It is necessary to give the 'Manage translations for any entity that the user can edit' permission, which can be problematic if some atomic control on the translation permissions is necessary.

@Amstercad: I'm confused by your report... What does the SKU field have to do with translations? Your screenshot isn't a screnshot from the translation UI but from the form for creating a new variation?

We're also experiencing the same problem as @Amstercad.
When we try to add the translation for a product we get "The SKU "SOME_SKU" is already in use and must be unique."