[Closed] Wrongly translated Product Variants in secondary lang order viewed in primary

Hello,

I will share 2 further screenshots with you.

So in wp_icl_translations.jpg you see that the translation group should contain the id 212.660 and 248.923.
In wp_postmeta.jpg you can see that the linked variation should be with the id 248885 which is the correct one (212.660 is a completely different variation with differnent attributes but from the same parent).
In query-to_show-errors.jpg i created a query that shows where the issue occurs. You can see in the highlighted line that the element_id 212.660 is linked to 248.923 in wp_icl_translations but should be linked to 248885 instead.

In total i have 377 occurrences of that issue.

Hello,

I would say I did all of that steps of troubleshooting already several times on different systems.
As there are close to 400 variants with that issue, I don't really want to start doing anything manually. Is there a way to rebuild the translation tables somehow?

I will run all of the provided steps tomorrow morning ~ in about 5 hours. But could you please ask your second level support if there is any script or something else that could be done to fix those entries. I really need that issue to be gone as it drives my customer crazy. (understandably)

Hello,

sadly nothing of the automated actions helped.

I really understand that you have your support protocols in place but please understand that just trying to fix stuff with automated actions in cases where they actually can't help due to the action they should do, is quite annoying for a customer when he already went through a whole lot of debugging, db duplication, process debuggin (xdebug) and so on and already presents you with the issues that exist in the database and just needs a possibility to fix the issue.

I would have to set up a new staging environment in that.

It had todo with using the new import export plugin and the new variables for translation groups. Due to a mistake the translation group custom field was set the same for all variations of a variable product. So instead of 1 entry for each language in the translationgroup, there where multiple e.g. 50. So it seems that it just took the first it found then and assigned the other language to it.

Even though it was our mistake, that lead to the confusion I would highly recommend a security check before running any linkings are done by the "WPML Imports & Exports" Plugin.

It should be checked if there are more database entries with the same translation group value set then there are languages. That would be easy to implement and can save users from loads of corrupting imports.

Please let me know if something like that is implemented. Because even though I know now what the issue was, mistakes do happen all the time and it would be really nice to know, that that issue can't come up again.

Hello,

i thought that the issue was resolved due to the fix of the sku, but it seems that it is still there and just happening when there are more than 5000 entries to process and the database is running on mariadb. As I assume, that the environment you sent me is running mysql 8 and not maria db i think i won't be able to replicate the issue there.

I could replace the following tables on a staging environment if you want me to, that should replicate the issue (all wp_icl_* tables + wp_posts + wp_postmeta)

After the fourth run it finished the cycle now after total 1h or so, but I think that it is not really the goal of the new plugin, that it is not working on mariadb or only partly on a high end server

The "old" way does work, but as far as I understand, it is the goal to abandon the WP all Import Plugin (it is marked as legacy) so I would really like the new plugin to work great before some compatibility issues arise. If you don`t think so, please redirect the issue to someone who can help me to fix the issues the import & export Plugin.