[Assigned] WPML Translation Dashboard stuck on “Loading items…” – possible ATE/queue issue

Hi Osama,

Ok thank you, I'll ask Hetsher to try this.

Best regards,

Erik

Hi Osama,

Did you here anything back from the 2e tier support about this issue?

Regards,

Erik

Hi Osama,

Thank you for the update.

I understand the suggested workaround using Yoast Duplicate Post, and I appreciate the confirmation that this is indeed a database-level issue.

Before applying this workaround, I want to be careful, as this site has:

existing indexed URLs,
multiple languages,
and SEO-sensitive content.
Cloning pages would create new post IDs and URLs, which is not ideal as a structural solution and may introduce additional SEO side effects.

Given that 2nd-tier support has identified this as a database issue, I would prefer to address it at the source if possible - for example by:

cleaning or rebuilding the affected WPML translation records,
resetting locked translation jobs,
or repairing inconsistent entries in the WPML tables.
Could you please confirm whether a database-level fix or cleanup is possible on your side, now that the root cause has been identified?

If needed, I can of course test the workaround on a single non-critical page, but I’d prefer to avoid duplicating live content unless there is no alternative.

Thanks again for your help.

Best regards,

Hesther

Hi Osama,

I’ve completed the test you requested on a non-critical page. Below is a clear and final summary of the results.

Result of the test

After duplicating the page and assigning the original slug to the duplicate (test performed on the Privacy Statement page, Dutch → English):

The WPML translation editor opens normally
The translation can be saved / closed without redirects or warnings
The editor no longer falls back to the WordPress/Elementor editor
This confirms that the original blocking issue was caused by legacy database relations tied to the original post ID, not by the page content itself.

Remaining issue (important clarification)

Before these problems started, my site worked for years in local translator mode:

I only saw pencil icons
I edited translations directly myself
After saving, the icon returned to a normal pencil
Translations were never treated as “jobs” or reassigned
After the workaround:

The editor is functional again (good)
However, WPML now treats the translation as a translation job:
gear icon instead of pencil
messages such as “waiting for available translator”
in WPML → Translations, the same page appears with conflicting statuses (e.g. “needs translation” and “completed but needs update”)
This workflow behavior did not exist on my site before the issue and indicates remaining inconsistencies in WPML’s translation records.

Conclusion

The workaround successfully restores the editor and proves this is a database-level issue.

However, duplicating pages one by one is not a sustainable solution for a multilingual, SEO-sensitive site, and the original local-translator workflow has not been fully restored.

Question

Now that the root cause is confirmed, is it possible for 2nd-tier support to perform a database-level cleanup/reset of WPML translation data so the site can fully return to the original local-translator workflow (pencil icons, no translation jobs), without duplicating pages individually?

Thanks again for your help and for escalating this to 2nd-tier support.

Best regards,

Hesther

Dear Osama,

I am following up on the issue that has been blocking my live WooCommerce website since December 8.

I understand that this case has been escalated to 2nd-tier support. I also acknowledge that a workaround was suggested (duplicating pages). However, this does not resolve the underlying problem. Pages remain marked as “outsourced to another translator / in progress”, which prevents me from:

editing content,
managing translations myself,
and safely updating or adding products.
As a single site owner and editor, this effectively means I cannot work on my website.

At this point, I need one of the following:

A workable temporary solution that restores full editing control, or
A clear and realistic timeline for a permanent fix.
Could you please clarify:

whether this issue has been identified internally as a known bug,
whether a developer is currently assigned,
what exact action is being taken,
and what the next concrete step will be?
I would appreciate a clear update on how and when this will be resolved.

Kind regards,

Hesther van Doornum