|
Hi,
We reviewed all the provided videos in detail and performed an in-depth technical analysis (including local testing with your site data). Below is a clear summary of our findings and conclusions.
General observations
* The issues you are experiencing are not related to a single post, language, or editor.
* The behavior depends primarily on how translations were originally created (WPML native editor vs Advanced Translation Editor), not on whether the post uses Gutenberg or Elementor.
* Elementor-based posts behave consistently and as expected.
* Gutenberg-based posts show inconsistent behavior in some scenarios, which we consider a real issue on our side.
1. Inconsistent “Needs update” vs “Completed” statuses
* After editing certain Gutenberg posts, only some languages are marked as “Needs update” while others remain “Completed”.
* This happens even when the same type of change is made (for example, modifying or adding a link).
* All translations should be marked as “Needs update” in these cases, but this does not always happen.
* This behavior is incorrect and should not occur.
* We were able to reproduce this issue internally with other posts, although it is no longer reproducible on the original post because it was already converted to Elementor in the provided package.
As part of our investigation, we identified a workaround at code level that addresses this issue. The problem is caused by an empty value being treated as valid content when detecting changes.
This is within plugins\sitepress-multilingual-cms\addons\wpml-page-builders\classes\Shared\AutoUpdate\Hooks.php, line 81:
Current behavior (problematic):
return Maybe::of( $post->ID )
->map( [ self::class, 'getPackages' ] )
->map( Fns::map( $joinPackageStringHashes ) )
->filter() // Empty value is treated as valid
->map( Lst::join( self::HASH_SEP ) )
->getOrElse( $content );
Proposed workaround, so the above should be replaced with:
return Maybe::of( $post->ID )
->map( [ self::class, 'getPackages' ] )
->map( Fns::map( $joinPackageStringHashes ) )
->map( Lst::join( self::HASH_SEP ) )
->filter() // Filter after joining
->getOrElse( $content );
By applying the filter after joining the package strings, empty results are correctly ignored and WPML can properly detect content changes. This workaround is currently under verification by our Compatibility team.
If you would like, we can guide you through testing this workaround on a staging or testing server.
2. Why link-only changes sometimes trigger high credit usage
* Credit usage is calculated based on a comparison between:
* The current English content
* The last completed translation created using the Advanced Translation Editor (ATE)
* If a language has never been translated using ATE (only via the WPML native editor), WPML does not store the original content for comparison.
* In such cases, when the content is sent to ATE, WPML treats it as if it were never translated before and charges for the full word count.
* This explains why adding or modifying a simple link can sometimes result in a large estimated and charged word count for certain languages.
3. Why word counts differ per language
Different word count estimations are expected and correct, based on translation history:
* Languages showing 0 words
* These already have up-to-date ATE translations.
* No content difference is detected, so no credits are charged.
* Languages showing a small number of words (for example, 6 words)
* These have existing ATE translations, but the stored version is slightly outdated.
* Only the difference is charged, not the full content.
* Languages showing a large number of words (for example, 132 words)
* These were originally translated using the WPML native editor.
* No ATE history exists, so WPML must translate the entire content from scratch.
4. Important clarification
* The issue is not related to Gutenberg vs Elementor.
* What matters is whether a translation was created using:
* Advanced Translation Editor (ATE), or
* WPML native editor
* If a translation was created using the native editor, WPML treats it as “never translated” when sending it to ATE later.
5. Why Elementor appears to “fix” the issue
* Elementor itself is not the fix.
* Converting a post to Elementor often leads users to resend translations via ATE, which creates a proper ATE translation history.
* Once a language has an ATE translation, future updates are charged only for differences and behave correctly.
* However, the initial conversion and resend can trigger a high credit estimate, which is understandably confusing and frustrating.
6. Options going forward for older posts
Unfortunately, for posts that were originally translated using the WPML native editor, there is no way to retroactively link them to ATE without cost.
The available options are:
* Continue updating translations directly in the WPML native editor (recommended for existing content).
* Convert the post and resend translations to ATE, accepting that the first resend will be treated as a full translation.
* Avoid resending Gutenberg posts with mixed translation history to ATE until the identified issue is fully resolved.
Summary
* The mixed “Needs update” / “Completed” status after Gutenberg edits is a real issue on our side and is being investigated (you can try the workaround above)
* Credit usage is technically correct but confusing when languages have mixed translation history.
* Elementor posts behave correctly because they consistently use ATE.
Let me know if you have any questions related to the above.
|
