[Waiting for user feedback] "Custom Link" and "Post Type Archive" items in menus aren't being translated properly

Hi Andreas,

The pages are translated and published. I tried the WP Menus Sync option, but that showed no changes, and syncing didn't resolve it. Actually, having read that document you sent... it now appears that running the menu sync manually will disable the automatic WP menu creation. I did NOT want to disable that, but it appears I have done so by running that manually. How do I revert this back to fully automatic so WPML may create WP menus?

I increased the memory limit (to 256 instead of 128) before doing any of that, but that seems to have made no difference.

So it doesn't appear that the manual WP Menu Sync is the solution, and it has no disabled part of my automatic translations. Where do we go from here?

So what about the items that are "Post Type Archive" types? These are built-in (WordPress default) dynamic pages that are created for any registered post types that have "archives" enabled, so these ones should work just fine, right? It's just the custom links that require a manual "prod" via the string translation feature.

I did spend some time explicitly telling WPML to translate those custom link strings. I was able to find them when searching via the String Translation menu, and queued them all up for translation. However they still don't seem to be getting translated. They will show as "Translation in progress to [language]" in the String Translation page right after queueing them up, but if I view the "Translation Management" page and filter to in-progress items, I don't see any of those ones appearing there. In fact, I see a handful of items here that appear to be old content that's stuck. These items are all mostly translated, but they all have at least one language untranslated that's reporting "[language]: Waiting for translator" even though all of the translations are set to be automatic. Why would it be waiting for a human translator for just a random single language, while it translates all of the others just fine? It's set up to perform translations automatically so I have literally no clue why it would be holding up translations for content for random languages.

I think there might be multiple issues going on here, so if I could just hop on a quick call to walk through config settings, I think that would be beneficial to rule out any bugs. I have only used WMPL on a few sites so far so I'm still learning how to navigate these more complex issues, but it's sometimes hard to tell what is a bug vs what is officially supported for automatic translations vs what I need to do manually to accommodate the limitations.

Hi Andreas,

I don't see anything in the String Translation for those, so I think it must be something else going on, or I'm just doing it wrong.

Would you mind having a look and see if you can find out what is going on? I've set up a dev environment and some credentials for you. The dev site is configured to share the pay-as-you-go translation plan, so that shouldn't hinder you when troubleshooting.

***CREDENTIALS REMOVED BY SUPPORT AGENT***

Let me know if I can provide any further information to assist you.

Hi Andreas,

I was just trying to take another pass at this but I'm currently unable to even access the WP Menus Sync page in either the live or dev websites. It times out with a 502 error after a full minute. This is not intermittent, it happens every time. I can't visit the page to reconfigure anything.

I disabled all plugins aside from WPML and the WPML helper plugins, as well as the plugins they directly support. This means that WooCommerce and Gravity Forms, among others, remained enabled along with their companion WPML plugins. I also switched to a generic theme to rule that out as well.

No luck with any of that, so I queried WPengine support for some additional info, and it appears that WPML is hitting the database super hard and is somehow unable to complete the process before WPengine's long process killer kills the task. The limit is 60 seconds, which I believe is quite standard, so I assume this means that there may be a bug/issue with WPML.

I can share my chat transcript with support directly, if you have an email address that I could forward it to. In lieu of that though, I'll just copy/paste some key bits that I believe are relevant for you.

Image showing a big mysql spike correlating to the visit to the WP Menus Sync page.
hidden link

The query itself, plus some additional info that appears to be some mysql debug info that I'm not familiar with:

it.element_id, it.language_code FROM wp_icl_translations it JOIN wp_posts pt ON pt.ID = it.element_id AND pt.post_type = 'nav_menu_item' AND it.element_type = 'post_nav_menu_item' AND it.language_code NOT IN ('en','bg','zh-hans','zh-hant','hr','cs','da','nl','et','fi','fr','de','el','hu','ga','it','ja','ko','lv','lt','mt','pl','pt-pt','ro','sk','sl','es','sv') JOIN wp_icl_translations io ON io.element_id = 412 AND io.element_type = 'post_nav_menu_item' AND io.trid != it.trid JOIN wp_posts po ON po.ID = io.element_id AND po.post_type = 'nav_menu_item' JOIN wp_postmeta mo ON mo.post_id = po.ID AND mo.meta_key = '_menu_item_object_id' JOIN wp_postmeta mt ON mt.post_id = pt.ID AND mt.meta_key = '_menu_item_object_id' JOIN wp_icl_translations page_t ON mt.meta_value = page_t.element_id AND page_t.element_type = 'post_page' JOIN wp_icl_translations page_o ON mo.meta_value = page_o.element_id AND page_o.trid = page_t.trid WHERE ( SELECT COUNT(count.element_id) FROM wp_icl_translations count WHERE count.trid = it.trid ) = 1 /* From [akbiodev.wpenginepowered.com/wp-admin/admin.php?page=sitepress-multilingual-cms/menu/menu-sync/menus-sync.php] in [/nas/content/live/akbiodev/wp-content/plugins/sitepress-multilingual-cms/inc/wp-nav-menus/wpml-menu-sync-functionality.class.php:250] */:

*** row 1 ***
table: io
type: const
possible_keys: el_type_id,id_type_language
key: el_type_id
key_len: 251
ref: const,const
rows: 1
Extra: NULL
*** row 2 ***
table: po
type: const
possible_keys: PRIMARY,type_status_date
key: PRIMARY
key_len: 8
ref: const
rows: 1
Extra: NULL
*** row 3 ***
table: mo
type: ref
possible_keys: post_id,meta_key
key: post_id
key_len: 8
ref: const
rows: 10
Extra: Using index condition; Using where
*** row 4 ***
table: page_o
type: ref
possible_keys: trid_lang,trid,id_type_language
key: id_type_language
key_len: 9
ref: wp_akbiodev.mo.meta_value
rows: 1
Extra: Using index condition

Hopefully this is helpful to you and your team. This is presenting a hard barrier for me to proceed with troubleshooting the other menu issue.