DeepL glossary entries ignored for several NL→X target languages (NL→ES, NL→IT, NL→PT, NL→...

This is the technical support forum for WPML - the multilingual WordPress plugin.

Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.

Tagged: ATE, Bug

This topic contains 23 replies, has 0 voices.

Last updated by Dražen 1 month, 2 weeks ago.

Assisted by: Dražen.

Author	Posts
July 17, 2026 at 6:30 am #18163103
Dražen Supporter Languages: English (English ) Timezone: Europe/Zagreb (GMT+02:00)	Hi, Thank you for testing this so thoroughly and for sharing such detailed findings. I'm sorry to hear that the issue is still occurring. Based on the fix that was deployed, I expected this to work. Let me check with our development team again and share your latest observations, especially the fact that the glossary suggestion is visible in ATE but is not actually being applied to the translation output. It's possible there is an additional issue here beyond the one that was originally fixed. I'll get back to you as soon as I have more information from the team. Thank you again for your patience and for helping us investigate this. Kind regards, Dražen
July 17, 2026 at 9:54 am #18163475
Dražen Supporter	Hi, Thank you for your patience. I checked this further with our team, and we noticed something that may explain the behavior. Glossary terms are currently case-sensitive. In your glossary, the source term is defined as `nederlandse gids` (all lowercase), while in the translation jobs and the examples you shared, the source text is `Nederlandse gids` with a capital "N". Could you please try updating the glossary entry so that it matches the source text exactly, including the capitalization, and then test again? Let me know how it goes. Kind regards, Dražen
July 17, 2026 at 12:41 pm #18163916
rigtmarB	Hi, Thanks for the update. I updated the glossary entry so that it matches the source text exactly (Nederlandse gids) and tried "Update Translations" and "Edit Translation" hidden link, the same result in both cases, as yesterday. The glossary rule is ignored. I suppose this is not a case sensitivity issue, since the ATE still sees the phrase (and saw it yesterday, when the rule was lowercased) and suggests the translation, but it does not apply it. Regards
July 17, 2026 at 12:51 pm #18163922
Dražen Supporter	Hello, thanks for checking, let me share this back with our team so they can check further. Regards, Drazen
July 17, 2026 at 2:17 pm #18164126
Dražen Supporter	Hello, we have checked and we see it is translated just fine for example for DE language, image attached. Can you please share ATE job ID / URL where this issue still happens, since I see for this page only job for today is for DE language and it is translated correctly. Regards, Drazen
July 20, 2026 at 10:43 am #18166847
rigtmarB	Hello, This one is a good example. Even in your screenshot, it works as expected for Youast Wpseo fields, but not for 3 others. The "Header Featured 1 Main Title" is uppercase, ok, maybe clear why it did not work. But for the "Main Page Content" the "Nederlandse gids" turns into "guide aus den Niederlanden", and for "Page Subheader" into "niederländischen Guide". So it is not fully correct. Regards
July 20, 2026 at 11:06 am #18166862
Dražen Supporter	Hello, You're right. Looking at your example, it seems that the glossary is being applied correctly in some fields. I'll report this back to our Advanced Translation Editor team so they can investigate further Thank you for your patience once again 🙂 Regards, Drazen
July 21, 2026 at 1:06 pm #18169083
rigtmarB	Hello, Pulled the stack trace for the TypeError — it fires inside the REST batch endpoint: WPML_REST_Posts_Hooks::reload_wpml_post_translation(): Argument #2 ($handler) must be of type array, null given #3 respond_to_request → #4 serve_batch_request_v1 → #5 respond_to_request → #6 serve_batch_request_v1 → dispatch WordPress passes null as $handler on batch sub-request paths, and the strict array $handler typehint on your rest_request_before_callbacks callback throws a fatal inside the batch loop. Since the block editor / ATE / "Update translations" flows use the batch endpoint, this fatal may be aborting the very save/update operations we're testing for the glossary issue — which would explain why "Update translations" completes with no changes. Could the developers (a) fix the typehint to tolerate a null handler, and (b) check whether this crash is what's preventing glossary updates from being applied? Full stack trace attached. TypeError: WPML_REST_Posts_Hooks::reload_wpml_post_translation(): Argument #2 ($handler) must be of type array, null given, called in /app/wp/wp-includes/class-wp-hook.php on line 341 #0 -content/plugins/sitepress-multilingual-cms/classes/REST-hooks/class-wpml-rest-posts-hooks.php(165): WPML_REST_Posts_Hooks::reload_wpml_post_translation #1 /wp-includes/class-wp-hook.php(341): WP_Hook::apply_filters #2 /wp-includes/plugin.php(205): apply_filters #3 /wp-includes/rest-api/class-wp-rest-server.php(1255): WP_REST_Server::respond_to_request #4 /wp-includes/rest-api/class-wp-rest-server.php(1861): WP_REST_Server::serve_batch_request_v1 #5 /wp-includes/rest-api/class-wp-rest-server.php(1292): WP_REST_Server::respond_to_request #6 /wp-includes/rest-api/class-wp-rest-server.php(1861): WP_REST_Server::serve_batch_request_v1 #7 /wp-includes/rest-api/class-wp-rest-server.php(1292): WP_REST_Server::respond_to_request #8 /wp-includes/rest-api/class-wp-rest-server.php(1125): WP_REST_Server::dispatch #9 /wp-includes/rest-api/class-wp-rest-server.php(439): WP_REST_Server::serve_request #10 /wp-includes/rest-api.php(467): rest_api_loaded #11 /wp-includes/class-wp-hook.php(341): WP_Hook::apply_filters #12 /wp-includes/class-wp-hook.php(365): WP_Hook::do_action #13 /wp-includes/plugin.php(570): do_action_ref_array #14 /wp-includes/class-wp.php(418): WP::parse_request #15 /wp-includes/class-wp.php(821): WP::main #16 /wp-includes/functions.php(1343): wp #17 /wp-blog-header.php(16): require #18 /app/index.php(17)
July 23, 2026 at 5:32 am #18172620
Dražen Supporter	Hi, Sorry for the slightly delayed reply. We checked this further, and the issue comes from DeepL. Unfortunately, this is outside of our control, and we can't influence how DeepL applies glossary entries. This behavior has already been reported to DeepL. This is also mentioned in our documentation: WPML’s glossary feature works when translating with PTC and DeepL, but not with the Google or Microsoft translation engines. This is because the available methods of integrating WPML glossaries with Google and Microsoft are either too complex or produce lower-quality translations. We recommend using the glossary with PTC for the best results. PTC fully understands your site's content and applies glossary terms intelligently instead of simply replacing words. In addition, PTC will always apply glossary entries, while DeepL may ignore a glossary term if it determines that another translation is more appropriate. You can find more information here: - https://wpml.org/documentation/translating-your-contents/advanced-translation-editor/how-to-create-and-manage-glossary-entries/ We recommend using our PTC translation engine, as it is fully integrated with WPML and is something we can actively improve and fix when issues arise. With PTC, glossary entries works as expected. I know this is probably not the answer you were hoping for, and I'm sorry about that. Unfortunately, some aspects of third-party translation engines are beyond our control. The best fix at the moment is to use PTC if consistent glossary application is important for your translations. Please let me know if you have any other questions or doubts about my reply. Kind regards, Dražen