experiencing same issue here, product in other language will remain as simple product.

Same issue here.
I created the variations/attributes in the default language and created the products in that language first. Then I created the variations/attributes for the second language (connected to the default language). And then when I try to create the translation of a product I either I cannot use the variations (inactive) or the product doesn't show them on the front-end, not even in the default language (which before creating the second language were showing the variations correctly)

Please, help!!

If i undestood correctly, this is happening for custom attributes, i.e. attributes that you create in the add product page. Have any of you tried defining the attribute as global attribute, i.e. create the attribute in the Product -> Attribute, translate in both languages before creating the product in any of the languages.

I'm setting variations this ways and is works reasonably well. The issue is that the default variation is not synced. This means when you update the product on language A, product in language B will get the default unset. To overcome this, I unselected the plugin settings to lock the sync fields (top of my head, don't remember the name of the option) and set the default variation manually on each product just by hitting save variations (don't use update product).

Have not tested the stock sync problem. I will check if I can reproduce it also.

Hi decarvalhoaa,
thanks for your help. I created the attributes for variations as global attributes and assign them to the products in German (250 products). Then I translated those attributes, also as global ones, and assigned them to those products in english.
So, when I translated the attributes I already had the 250 products created in one language. And now it's not working for the second language. If i have to start all over creating products I will have to switch to WPML.
Now if I create a new product and assign the attributes in the respective languages, the front-end dosn't show any of the attributes, neither in german nor in english.

I had a similar problem with variation products:

• create a new variable product with some attributes
• translate product
• when you hit the publish, attributes disappear from the original and from the translation

I tracked that this bug happens also in normal products that have attributes.

I might have found a solution for this. The problem seems to lie in the WooCommerce's way to get the attribute terms for the admin UI. For some reason, it cannot get always the translations and when it returns empty handed, the empty attributes are synced to the original. (If your variable product lost it's variations, just add the attributes back and the variations come automatically back, too).

I made a pull request to WooCommerce to add some filters there woocommerce/woocommerce#11049 so that we can make our own filters there that take care of this bug.

I'll get back to this issue when I get response from WooCommerce devs and have tested my solution more. If I forget, please send me angry messages.

I fortunately I don't have this issue. Truth be told, I only used so far Global attributes fully translated before I attempt to translate the product. The only issue I have (still need to find the issue to track it down) is the default variation is unset if/when I press publish/update.
My workaround is to unlock fields in the Hyyan plugin settings, and then set the default variation by pressing the "save attributes" instead.

Are the attributes you create global or product custom? If global attributes, are they translated before you translate the product?
Have you try creating in the original product all attributes (original attributes and respective translations) and only create the variation from the ones that apply for the original or translation respectively?

Based on your debugging, do you think that my "default unset" issue may be related?

Cheers
A

By the way, regarding stock sync. In my case, only the refunds of variations are not sync. Simple products work fine both for orders and refunds.

My pull request to WooCommerce got through and I will present you my solution. My filters to WooCommerce (woocommerce/woocommerce#11049) are going to appear in next version of WooCommerce, so this solution won't work for you until the next release unless you modify the WooCommerce source files yourself.

Add this to your functions.php:

add_filter('woocommerce_product_attribute_terms', 'fix_woopoly_attributes');
function fix_woopoly_attributes( $args ) {

  $lang = '';
  global $post;

  if(isset($_GET['new_lang'])) {
    $lang = esc_attr($_GET['new_lang']); // new translation
  } elseif( !empty($post) ) {
    $lang = pll_get_post_language($post->ID); // edit post
  } else {
    $lang = PLL()->pref_lang; // new product
  }

  $args['lang'] = $lang;
  return $args;

}

You can also display the language of an attribute term with:

add_filter('woocommerce_product_attribute_term_name', 'woopoly_show_attribute_lang', 10, 2);
function woopoly_show_attribute_lang( $name, $term ) {
  $lang = pll_get_term_language($term->term_id);
  return $name . ' (' . $lang . ')';
}

I'll make a pull request for this fix when WooCommerce has released a new version. The problem with disappearing attributes (and variations) is in UI: if WC can't find translation of attribute, when saved it is handeled just like attributes were deleted. This deletion is then synced to translations.

If I make the pull request here, will the forkers find it? Which fork is the most popular? I can make the pull request right there.

I'll take a look in stock. It's probably a separate bug (if there's any problem).

I made some tests locally in fresh installed WP + Polylang + WC + WooPoly. When I ordered a variation product, the variaton stock was updated correctly in both languages. When I made a refund and increased the stock (in the order edit screen), the stock was updated correctly for both languages. All in all, I didn't find any problems with stock syncing.

I'll get back with a pull reguest when WooCommerce is updated. If you have an active fork, I can make pull reguest directly for you. Let me know.

I and Harrase have been collaborating to fix the emails, shipping methods and payment gateways issues. This is all solved in my Development fork.

I have also have been back porting patches from other guys.

Harasse has been in contact with Hyyan whether he plans to resume the plugin development. We don't have a ETA for when this will happen, but I and Harrase have consider publish my fork in Wordpress.org, attribute the credits to Hyyan, and continue to develop the plugin at least until Hyyan is back.

I Have also been working with the owner of the popular https://wordpress.org/plugins/woocommerce-pdf-invoices-packing-slips/ plugin to add support to polylang and Hyyan plugin, that is not in testing.

I would suggest pull your fix both here and on my fork that maximize the reach to all forks.

If we publish this in Wordpress.org would welcome more contributors like yourself. What you think?

Reagrding stock sync issues, if you still have the local fresh install, can you check if you can reproduce this issue decarvalhoaa#4 (quick edit changes on the product listings page are not sync with translations) ?

I can help you tackle issues but I have also full-time WordPress developer job and a few side projects that take my time. I have a couple sites that use WooCommerce and Polylang so I have a vested interest in making sure that everything works correctly.

I'll try to make the pull request for attribute problem already because it doesn't hurt to apply them already (it's a filter so nothing breaks).

Regarding to the quick editing bug (decarvalhoaa#4), I can confirm that it is broken. I tested it by creating a normal product and a translation for it. I changed a discount price in quick edit view and it didn't sync. The problem is probably in the hooks that the integration uses (so that those fire only on regular edit screen). I'd take a look in there. I might be able to do some digging there as well since I have done some work on copying stuff across translations (https://github.com/aucor/polylang-copy-content).

There's at least one more active bug that I am aware of. It's abot coupons. I reported it some time ago, made an ugly work around, but didn't try to find the root cause for it. #27

About the future of Polylang and WooCommerce, Chouby (the developer of Polylang) has announced that he is working on official add-on to Polylang Pro version that integrates Polylang and WooCommerce. This will be a premium plugin, though. You can get the beta if you order the Polylang Pro and send request for WooCommerce beta (https://polylang.pro/). In the future, there might be a need to figure out a way to move from this integration to the official version and seek out bugs in there. I will help you with this as I have time (and skills) but I hope you take the lead on developing if Hyyan won't.

Hi TeemiSuoranta

how does adding the language of the product translation to the array of attribute terms

$args['lang'] = $lang;

will help WC find the attributes?

Hi decarvalhoaa!

The whole edit post/page/product screen in WordPress is basically a big form element. The values that exist or have been saved before are inserted in inputs when you go and edit existing product. When you save the product, WordPress does some logic to figure out which values have been altered and updates things accordingly.

Now, the problem with attribute terms isn't in the translation part. When you create a translation of product the right attributes are set initially, I think. The problem becomes in that "inserting existing values in edit screen input" phase. The get_terms function fails to get the correct terms (attributes) and when product is updated, WordPress figures out that you have deleted attributes (because input has none) and removes the attributes.

If you use get_terms function anywhere in your theme, Polylang sets the language neatly for you. This is probably done with some filter. For whatever reason, Polylang fails to set the language here. This might have something to do with the fact that Polylang can't figure the current language so easily when creating new product or new translation (https://wordpress.org/support/topic/find-out-current-language-in-post-newphp?replies=3)

With my solution, we'll give Polylang a little help and tell in which language the current product is. Now the values from database are inserted correctly and updating product doesn't break anything.

PS. The bug was that by updating the translation deleted all the attrbitutes from all languages. This is because attributes are synced and when the attributes were removed by the bug above in a translation, the attributes disapppear from all translations. This was fixed in the solution.

I'll try to make those pull requests in the coming week.

But will than Polylang by aware/ check out $args['lang'] if all other methods to find out the lang failed?

The $args['lang'] overrides whatever Polylang has set as a default. In theme you can for example query terms in different language than the current language. I have this solution in production and it's working like a charm.

Sorry for the delayed PR. I'll do it tomorrow. New version of WooCommerce is released and my filters are included there and this fix is ready to roll.

Merged @TeemuSuoranta PR to solve the problem