We have migrated content from another site, importing XLIFFs. The translations are all showing on the frontend, and are connected properly – but when going to edit them in the ATE, they are (almost) all blank/missing.
We do not wish to use the Automatic Translation option, since we already have the confirmed translated content in place. Or would the automatic translation check for existing translations first, and use those instead?
If not – how can we populate the strings in the ATE without copy/pasting manually (too much content).
The site is using WP/Gutenberg Blocks, and the block markup is identical per language. We only want string translation, not visual changes.
In the Classic Editor, the fields are populated with the original language (Norwegian) text, even though they display translated (e.g. English) on the front-end. See screenshot.
Thanks for the detailed explanation — based on what you described, it’s expected that the Advanced Translation Editor (ATE) shows the content as blank after a migration/import of existing translations (XLIFFs created/handled outside of WPML’s ATE jobs). ATE can only display content that exists inside its own translation jobs/memory, so it won’t automatically “pick up” already-imported translations that are already stored in the site’s database.
✅ For this kind of workflow (imported XLIFF translations), the correct editor is the Classic Translation Editor (CTE).
Why does CTE show the original language text then?
If CTE opens and the fields are filled with the **original Norwegian content**, while the front-end shows English, it usually means WPML isn’t loading the *stored translation package* for that item (or the translation is stored in a way that WPML isn’t treating as “CTE-managed”).
### Please try this to fix CTE loading the translation
**Option A — Force WPML to rebuild the translation package (recommended first)**
* Edit the **original (Norwegian)** page/post.
* Make a tiny change (e.g. add a space) and click **Update**.
* Now go to **WPML → Translations** (or the language box on the edit screen) and open the translation again in **Classic Translation Editor**.
* Check if the translation fields now load the translated content.
**Option B — “Refresh” WPML’s translation status**
* Go to **WPML → Support → Troubleshooting**.
* Run these actions (only these):
* **Clear the cache in WPML**
* **Remove ghost entries from the translation tables**
* Then re-open the same translation in **CTE** and check again.
**Option C — Re-send the page as a translation job and then open it in CTE**
This is useful if WPML considers the front-end translation as “existing content”, but the Translation Editor doesn’t have a proper “package” to load.
* Go to **WPML → Translation Management / Translation Dashboard**
* Select the affected pages/posts
* Send them for translation again (to the same language)
* Then open the translation in **Classic Translation Editor**
* If it prompts you to overwrite, stop there and tell us what message you see (because we don’t want to lose your imported translations)
**Option D — Confirm CTE is the active editor (so WPML doesn’t keep pushing ATE)**
* Go to **WPML → Settings → Translation Editor**
* Set **Classic Translation Editor**
* Save, then try opening the translation again
If, after Option A + B, the Classic Translation Editor still shows the original text, please tell me **how the translations were imported** (from WPML-exported XLIFFs or from another platform/tool).
Question: If we use the automatic translation tool – will WPML then use the existing (Classic) translations before it uses credits and creates new translations?
If not, it would mean existing translations would be overwritten?
Replacing proof read content across 5 languages, and simply trusting that AI makes it just as good, is not an option for us!
Hope there is some way to do this. I am comfortable using API or scripting to help achieve this.
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
Hello,
It may use it for some segments but I general it won't use it for big sentences because of the segmentation that the advanced editor uses.
We can help you get started by gifting you some credits if that helps but in general we suggest that if you're going to do this, do it only when you need to make changes to the page, so the work becomes gradual and less time consuming.
But yes, if you already proofread it, then it's better to copy paste it when you need to make changes to the page, that way the work is way less.
As mentioned, it is too much work to copy-paste everything manually. The content is spread across many blocks and patterns, in 100+ posts.
This is not something I want to do manually – but now I have spent days now trying to solve this in a different way.
What I am currently doing is using a custom script that intercepts the translation-job and replaces the Automatic Translations made by PTC before save.
This works, and my existing proof-read translations are showing up as they should in the Advanced Editor.
However – this is bleeding Credits, since I am paying to automatically translate the entire project only to disregard those translations before they are even saved.
I am surprised and disappointed that you do not have a good way to migrate existing translations into the ATE.
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
Unfortunately we do not have any other way to handle this. however may I know why are you using credits for this? I mean why do you need to use the automatic translation here in order to replace it afterwards? I refunded those credits but we can't do that for your entire site, only what has already been used.
When the page has first been translated, you can click the "undo" button or click the gear icon on the uppermost right side of the editor and disable the automatic translation altogether. would that work?
Unfortunately due to the dynamic nature of the segmenting feature, we can't reliably port the translations from the classic editor to the advanced one natively.
