Skip Navigation

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.

Sun Mon Tue Wed Thu Fri Sat
- 8:00 – 15:00 8:00 – 15:00 8:00 – 15:00 8:00 – 15:00 8:00 – 15:00 -
- 16:00 – 17:00 16:00 – 17:00 16:00 – 17:00 16:00 – 17:00 16:00 – 17:00 -

Supporter timezone: Europe/Rome (GMT+01:00)

This topic contains 46 replies, has 2 voices.

Last updated by Alejandro 3 years, 9 months ago.

Assisted by: Alejandro.

Author Posts
May 12, 2020 at 3:10 am #6108457

fernandoG-11

Hi Alejandro, thanks for the detailed response. After more testing, I believe the issue with the green "Save and complete" button is a (very minor) bug. Under Chrome 81 and Firefox 76 on Ubuntu Linux 20.04, hovering the mouse over the center of the button (directly over the tick) results in the cursor flashing between an arrow and the hand icon, while the button changes between two shades of green. I cannot reproduce this under Windows 10, or with any of the other buttons. It might be a problem with how Linux handles cursors? Video: hidden link

Regarding the XLIFF export/import, I cannot get it to work. Here are the procedures I tried:

(Method A)
1. WPML -> Settings -> How to translate posts and pages -> New content -> Use WPML's Advanced Translation Editor
2. Click "Synchronize translators and translation managers
3. WPML -> Translations -> Select a single completed translation job (e.g. Learning Resources in Dutch)
4. Export XLIFF 1.2 -> Apply. File is downloaded, translated content is visible inside the XLIFF file inside the ZIP file.
(At this point, editing the Dutch translation still takes me to the classic editor, since no new content has been added. This is expected behavior.)
5. Edit the English version by making a very small change. Translation icon changes to "Update".
6. WPML -> Translations -> Select file -> Upload. "Translation of job 4355 has been uploaded and completed."
7. Edit Dutch translation. Translations are not visible, all target segments still in English.

I also tried this approach, starting after step 4 (Method B):
5. Upload the file without editing the English translation first. This doesn't work, the classic editor appears again.

And this approach, starting after step 4 (Method C):
5. Edit the English version by making a very small change. Translation icon changes to "Update".
6. Edit the translation before uploading the file. ATE appears, all targets in English. Click "Back to list". Translation icon changes to "Edit" with the in-progress cogs showing.
7. WPML -> Translations -> Select file -> Upload. "Translation of job 4355 has been uploaded and completed."
8. Edit Dutch translation again. Translations are not visible, all target segments still in English.

What am I doing wrong? I can't understand from the documentation you linked how this process is supposed to work...

May 12, 2020 at 10:19 am #6111297

Alejandro
Supporter

Languages: English (English ) Spanish (Español ) Italian (Italiano )

Timezone: Europe/Rome (GMT+01:00)

Let's do this, so i can also test and see what's happening.

To be on the same page as you and replicate the problem exactly as you did, let's use a reference page where you had this issue. I'll try to duplicate the page and check it out exactly as you did and see what happens, it will probably give me a clue on what's going on and i'll check everything before i come back.

I think i can be way mmore useful like this, what do you think?

Let me know.

May 13, 2020 at 1:36 am #6117437

fernandoG-11

Sure, that sounds fine. You already have the login, I suggest we use the "Contact" page since it is relatively simple and includes a single-level repeater field that we can easily rearrange to test functionality. At the moment the problem I am facing is I cannot import my existing translations into the ATE, using the steps I described above. Don't worry about preserving data or making a mess, the staging-www2019 domain is a sandbox and I can reset it if anything breaks. Thanks!

May 13, 2020 at 3:55 pm #6123941

Alejandro
Supporter

Languages: English (English ) Spanish (Español ) Italian (Italiano )

Timezone: Europe/Rome (GMT+01:00)

Here you go: hidden link

I'm explaining here in detail how the XLIFF file should be used, and what steps you could take.

Please remember that if you are going to download/upload a file you first need to go to WPML > Translation manangement and send it to the translation job queue, even if it was already there in the past (i didn't do this at the beginning of the video because i had already triggered and "update required" status on the translations so the system actually did all those steps under the hood).

By doing this you will create the "latest" unique ID that has to match with the uploaded XLIFF file.

That Unique ID is the value of the "Original" attribute in the XLIFF'S "File" tag.

I hope this was cleared enough and i hope that it would solve the problem you might be having.

Regards.

May 14, 2020 at 2:13 am #6127199

fernandoG-11

Thanks for the video Alejandro! The segmentation change is very welcome, segmenting at the sentence level makes much more sense for reusability of translations. And I am very happy to hear that the dev team in considering a way to add fuzzy matches - in your example you spent some time on a segment containing two sentences, and I would expect to see a ~60% match in those cases in most translation tools.

I really wish we could have a call to clarify this in realtime (which I think would take 10 minutes to demonstrate), because you just spent 25 minutes explaining a solution to a problem only tangentially related to the actual problem I am facing. Let me know if this is an option for you, until then, here is another video from me demonstrating exactly what is not working.

hidden link

May 14, 2020 at 11:54 am #6131797

Alejandro
Supporter

Languages: English (English ) Spanish (Español ) Italian (Italiano )

Timezone: Europe/Rome (GMT+01:00)

Hi!

What you show me in the video (minute 2:15) is kind of expected and an easy way to understand why let's summarize everything in 1 logic:

If it wasnt' translated in ATE, it will not show in ATE.

This is a restrictions we currently have, so if they come from somewhere else, the first step would be to pick the common denominator in different elements and translate them in ATE first so it gets stored and a translation memory.

So this is how it would go if you get it from somewhere else (say, a translation service)

1) You woudl import it in the site, and it would show in the front-end.
2) You'd now open ATE and the translation wouldn't show.
3) You'd copy the content in ATE and the strings would be stored there now and available for Translation Memory
4) They would now start showing everywhere those fields are present as it happened with the string i translated.

The XLIFF would still show the translations for sure because they are never going to be modified until you translate the entire page with ATE, but they are currently not picked up (As shown in minute 3:23) because as the devs tell me there's a restriction there because of many ways the translations are stored in the file, apparently that could cause many issues later down the road, but i would not be able to explain this in more detail.

I hope this makes it clear.

May 15, 2020 at 8:45 am #6139381

fernandoG-11

Thanks Alejandro, that's not the answer I was hoping for but I understand. So the only method seems to be to import it manually.

Where is the translation memory for ATE stored? What is the native database format, is it based on some open source or standard software library? Is there any option to import the standardized TMX format there? I'm thinking I could download the XLIFF files for a language in another CAT tool like TRADOS, ingest everything into a desktop TM and export TMX for import into the ATE TM. Manually copying everything over from XLIFF files is going to take many weeks and is very likely to result in user error.

May 15, 2020 at 6:03 pm #6143119

Alejandro
Supporter

Languages: English (English ) Spanish (Español ) Italian (Italiano )

Timezone: Europe/Rome (GMT+01:00)

I'm asking our developers for this information because that is a bit beyond my knowledge but i'll get back to you as soon as i have an answer from them.

Regards.

May 18, 2020 at 1:25 pm #6158193

Alejandro
Supporter

Languages: English (English ) Spanish (Español ) Italian (Italiano )

Timezone: Europe/Rome (GMT+01:00)

Hello,

I was told by the ATE team that they are actually working to implement something for this

Here's what they told me:

The desired LSP supports translation memory so if the client sends the translation again to the same LSP it will work, right?

ATE also supports Translation Memory , but needs to first be translated with ATE.

We will support at some point import / export of TM so if the
client gets the TM from the LSP will be able to import it in ATE

That's the way around the problem i mentioned earlier about the reason why the target language couldn't be read in ATE.

Right now, though, there's no way around this issue but to translate everything with ATE directly.

May 27, 2020 at 8:21 am #6226981

fernandoG-11

Thanks Alejandro. We started migrating the translations and it is a much bigger job than we anticipated, likely months instead of weeks. Expensive and very error-prone.

This leads back to a question I asked earlier about the ATE architecture: where is the TM actually stored? How can we manage it directly, instead of having WPML staff gatekeep it? What is the native database format? What are the actual obstacles to providing a file for you to import (instead of waiting for devs to implement an import function), is it money, time, lack of workflows...? Whatever your hourly rate is for a database import (to a TM filled with content we own but cannot access!), it is surely cheaper than the 200+ hours it will take to manually copy and paste everything over.

And also a couple more bugs/questions:

1. In cases where a translation is not available yet, but an incorrect translation is pasted in the field by mistake: how can we remove the incorrect translation from the translation memory? It is not possible to store a blank segment, and there is no delete function. Does this mean the incorrect translation is permanently saved in the TM?

2. As an example, I manually copied over translations from the classic editor to ATE on our testing site. I then changed the settings on the build site to use ATE, edited the page to trigger an update, and opened the ATE from the build site. All the translations appear as expected. However, it is not possible to complete the translation for the page, it always appears as "in progress". Modifications I make to the translation on the build site also do not appear on the translated pages. What am I doing wrong?

Video for question 2: hidden link

May 27, 2020 at 2:22 pm #6230107

Alejandro
Supporter

Languages: English (English ) Spanish (Español ) Italian (Italiano )

Timezone: Europe/Rome (GMT+01:00)

I asked our developers to take a look at your last answer and they told me they were going to check it out and come back to me.

About your questions:

1. It's not going to be permanently stored in the TM. You can override it with another value and that value will take over the initial translation. you can also add it to the glossary (the book icon you can see in each segment) so you instead get a "suggestion" from the system asking you if that's the correct translation. this also works when one segment instead has more than just 1 translation, you can save them both and select the one you want afterwards.

2. From what i can see on my side, the translation that you showed me in the video is now correctly translated and should show the "pen" icon now.

Sometimes it might take a bit longer before the system (WPML) accepts the change and applies it to the site or if you have a server side cache, then it might just be that the site is showing you an old version of the site (rare but has happened before, specially when OPCache or REDIS is involved).

I waited on purpose before i could answer you and i monitored the status of the translation to see if it changed from "delivering" (which means that our system sent it to your site) to "delivered (which means that the site accepted the translation and applied it) and i can see it correctly now. could you check?

May 27, 2020 at 10:36 pm #6233443
fernandoG-11

Hi Alejandro,

no, the translation is still not confirmed. Note we are using two cloned WordPress instances here, since your reply from May 8 indicated that the TM would be shared if the ATE ID is identical.

1. Switch `staging-www2019` site to use ATE
2. Edit page to trigger update
3. Open translation, manually copy translations into ATE
4. Finish translation
--> Icon changes to pen indicating translation is complete on `staging-www2019` site.
5. Switch our live build site `www2019` to use ATE
6. Edit page to trigger update
7. Open translation, all translations already exist in ATE
8. Finish translation
--> Icon remains in progress, any changes to translation do not appear on the `www2019` site.

Regarding your response to question 1, this is problematic because the stored translation is incorrect and we do not yet have the correct translation. It should be possible to delete a translation from the TM, because now we have no way of marking it incorrect, and are not yet ready to send a batch of work to the translator, so we cannot enter the correct translation. We also cannot enter a blank translation. It will always fill the incorrect translation, since it sees a 100% match in the TM.

That basic management functions like this (and import/export) are missing in ATE is problematic. It means given our use of ACF, WPML has no functional translation editing solution. Classic editor mixes up translations, Transifex integration simply doesn't work, and now ATE cannot complete the translations...

New threads created by Alejandro and linked to this one are listed below:

https://wpml.org/forums/topic/problem-with-ate-translation/

May 28, 2020 at 1:52 pm #6240355

Alejandro
Supporter

Languages: English (English ) Spanish (Español ) Italian (Italiano )

Timezone: Europe/Rome (GMT+01:00)

Hello!

Our developers came back and told me that:

1) we can't display some of the information you are asking for because:
- It's for internal use only
- For security reasons

What i can tell you is that:

1) The Translation memory currently can only be overwritten with new content (it can't be erased) but one of the next updates for ATE is the Translation Memory Management where you will be able to import it, export it, rewrite it and delete it with a dedicated UI for it.

2) TMX will probably be one of the formats that you will be able to export to, exactly because it's a standard format but that still is being evaluated.

The ETA for this should be by Q3 this year but this is not a fixed date, it could change if the Unit tests return errors or if issues arise during the Alpha and Beta testing period.

3) The problem with the translations match between translation editors is that the segmentation match between XLIFF is impossible to do.

Here's an example:

Imagine you have this long text:

Michael the Brave (Romanian: Mihai Viteazu(l) pronounced [miˈhaj viˈte̯azu(l)] or Mihai Bravu pronounced [miˈhaj ˈbravu], Hungarian: Vitéz Mihály; 1558 – 9 August 1601) was the Prince of Wallachia (as Michael II, 1593–1601), Prince of Moldavia (1600) and de facto ruler of Transylvania (1599–1600). He is considered one of Romania's greatest national heroes.[2] Since the 19th-century Michael was seen by nationalists as a symbol of Romanian unity[3], as under his reign was the first time when all principalities inhabited by Romanians were under the same ruler.[4]

His rule over Wallachia began in the autumn of 1593. Two years later, war with the Ottomans began, a conflict in which the Prince fought the Battle of Călugăreni, considered one of the most important battles of his reign. Although the Wallachians emerged victorious from the battle, Michael was forced to retreat with his troops and wait for aid from his allies, Prince Sigismund Báthory of Transylvania and Holy Roman Emperor Rudolf II. The war continued until a peace finally emerged in January 1597, but this lasted for only a year and a half. Peace was again reached in late 1599, when Michael was unable to continue the war due to lack of support from his allies.

then you have the translation set in an XLIFF in another language like Italian:

Michele il Bravo (rumeno: Mihai Viteazu (l) pronunciato [miˈhaj viˈte̯azu (l)] o Mihai Bravu pronunciato [miˈhaj ˈbravu], ungherese: Vitéz Mihály; 1558-9 agosto 1601) era il Principe di Valacchia (come Michele II, 1593 –1601), Principe di Moldavia (1600) e sovrano di fatto della Transilvania (1599–1600). È considerato uno dei più grandi eroi nazionali della Romania. [2] Sin dal diciannovesimo secolo Michele fu visto dai nazionalisti come un simbolo dell'unità rumena [3], come sotto il suo regno era la prima volta in cui tutti i principati abitati dai rumeni erano sotto lo stesso sovrano. [4]

Il suo dominio sulla Valacchia iniziò nell'autunno del 1593. Due anni dopo iniziò la guerra con gli Ottomani, un conflitto in cui il Principe combatté la battaglia di Călugăreni, considerata una delle battaglie più importanti del suo regno. Sebbene i Wallachians siano emersi vittoriosi dalla battaglia, Michael è stato costretto a ritirarsi con le sue truppe e ad attendere l'aiuto dei suoi alleati, il principe Sigismund Báthory della Transilvania e il Sacro Romano Impero Rodolfo II. La guerra continuò fino a quando alla fine emerse una pace nel gennaio del 1597, ma questa durò solo per un anno e mezzo. La pace fu di nuovo raggiunta alla fine del 1599, quando Michele non fu in grado di continuare la guerra a causa della mancanza di sostegno da parte dei suoi alleati.

The content for both is the same (i google translated a random English wikipedia article) but the segmentation for both of them will be the same as well.

There is no way of knowing which segment will be correct in the translation because of the complexity of the different language structures so in the end, chances are the result will just be the same as not showing anything.

Our developers are still trying to figure out a way of achieving this, but so far it is not possible.

However, the ACF Bug with the Classic Translation Editor is passing all the tests and should be out for the next beta version onwards. a few changes have been made to both WPML and ACF so as soon as the next updates for both come out, you'll probably be able to use CTE again and migrate to ATE only when the Translation Memory import/export feature will be live, or you can at least migrate progressively without having to redo everything from scratch in one sitting.

May 28, 2020 at 10:35 pm #6244073

fernandoG-11

Hi Alejandro,

this is really disappointing. One of my first questions about ATE was where the translations are stored and whether we have access to them at all times, since we *own* these translations. You said we have control of the translations at all times, and export is always possible. Now the answer is that you are gatekeeping them on a separate server and they are actually not accessible "for security reasons", and if you make a mistake, you cannot erase it. The translations do not appear on the website, because it is impossible to mark the translation as complete. You also cannot export the translations, because the XLIFF export function only exports a translation that is marked as complete, which is not possible to do. So now we have invested hundreds of dollars manually migrating translations to a system that does not work, and cannot be fixed (until maybe sometime in Q3).

So the problem I currently need to resolve is this: why is it not possible to complete a translation when using ATE? The translation is 100% complete in ATE and I clicked finish. Why does WPML not see it is complete? How can I update content in any language other than English? I'm not clear what your current advice is, should we go back to CTE, try to fix ATE or just have a broken website until Q3?

Video of the problem: hidden link

Finally, when you say the bug in CTE has been fixed, which bug are you talking about? The Options page not reading the ACF field group correctly in non-English languages, or the original problem where re-ordering repeater fields results in mixed-up translations? I thought you said this required a fix from the ACF side to add an index to their repeater fields. Have they done this already?

May 29, 2020 at 7:05 am #6246411

Alejandro
Supporter

Languages: English (English ) Spanish (Español ) Italian (Italiano )

Timezone: Europe/Rome (GMT+01:00)

Hello.

The thing is that we are not really "gatekeeping" it as you mention. you do have control on your files, but the issue is that a proper file is not created until the translation is complete, so you can't "get" anything because of it, because it doesn't exist yet.

What i meant earlier about security reasons is that i can't really tell you how our infrastructure is made (Database Format or where the Translation memory is stored), that would create a huge backdoor and affect so many clients and we are not going to risk that.

You will be able to handle your translation memory but that system is not ready yet so we can't allow anyone to access it... yet (because there isn't any way to access it unles you have access to our systems as one of our develepers).

You mention that " The translations do not appear on the website, because it is impossible to mark the translation as complete.", but if the problem is the one you mention on your video, i previously explained that you're not getting it as complete because of the workflow you're following and you need to remove the translation job in the production site, and re-add it again, so you can then have ATE send you the correct translation, to the correct website (right now it's still sending it to the dev site, because that's the reference site our system has).

You can follow these step and it should work:

1) Do not touch the translation on the Staging site for now
2) Make a small change to the translation in the production site
3) save the change (do not revert it yet)
4) Go to WPML > Translation Management > Translation Jobs > Delete the translation job.
5) Go to WPML > Settings > How to translate posts and pages > Click "Sync local translators and translation jobs" button
6) Now you can revert the change on the page
7) Go to WPML > Translation Management and now add the job from this page
8) Proceed to translate it from WPML > Translations (only everytime you try to translate first in Staging and then in Production)

This should be able to have everthing working correctly.
You have to find the correct translation of that wrongly translated string that you wanted to change and rewrite it with the correct, otherwise, yes, you won't be able to have the XLIFF File because the XLIFF file will not be created until you finish 100% of the page (it's created when you click the "finish" button).

And again, if you have a clone that differs only by a URL, it's normal that you won't get it synced everytime in both sites because you still have 1 variable that is not the same in the entire ecosystem.

I would suggest you avoid translating the content in the staging site to then do the same in the production site right away but you can go around this workflow by following the steps i mention above.

Then about the ACF Bug Fixing, i meant the ACF Repeater bug, and i meant in my last ticket that it will be included in one of our next updates (and i'm sorry if that wasn't clear) and you also would get an ACF update as well.

By then, you would need to update both ACF and ACF Multilingual but that is not out yet. the same thing goes for the options page issue that will also be included in one of our updates.

I believe this ticket is getting too polluted already so by the next answer i'll start splitting it into separate issues so we can better understand each other (because at least in our last answers the problem seems to have been only of communication 🙂 )