This problem didn't exist a few days ago. I think the ATE has been updated and there is a bug in it. Here's the process:
1. Post is translated by an external individual translator.
2. I run a quick check in the DE front end first. No wrong characters are visible yet.
3. I enter the ATE to wrap up the post. I adjust page title and a few other details. I make a few more edits in the translated strings too and click "Complete".
4. I check the post's front end. All strings in which I made an edit and that contain a character with a diaeresis (Umlaut: ä, ü, ö, etc.) are now rendered wrongly: see screenshot. This happens to both characters I actually changed myself, as well as characters in the concerning string that I did not adjust.
5. I get back into the ATE. The concerning characters are now displayed wrongly in the editor too.
6. I adjust the concerning characters, click the check mark to confirm the translation, and complete the post.
7. The wrong characters are still or again visible in the front end, and when I return to the ATE they're messed up too. So this looks like a problem that arises when an initially translated item is edited and that afterward can not be solved through the ATE.
This stops is from editing any translations, so a quick fix will be appreciated.
thanks for contacting us and sharing further info.
I have just checked and seems it translates fine, so it could be that it was a one time thing.
Can you please try 2 things:
1) Make a small change to the default language page and save. Re-translate the page, make sure the text is corrected and save. Let me know fi tis helps.
2) Create a new dummy page and add only text "Prices for this city walk", check if the issue still happens.
I checked and seems the issue is not happening anymore but for you, the wrong, corrupted umlauts are saved in your translation memory.
So what you need to is re-translate and re-save the correct sentence in the ATE editor. Once you save and re-translated now new correct sentence it will work fine.
- hidden link
Why it didn't help you the first time you tried might be because you have had some cache plugin and object cache enabled, please make sure to disable it, translate, and then enable it back to not cause any confusion or issues.
By "re-translate", you mean go into the ATE, correct the sentence, and click "Complete"?
I did that and it makes no difference. Prior to that, I had cleared all caches and Object Cache Pro was disabled.
I found that if I use the HTML code of the character instead, it saves and displays just fine. For example: "& uuml ;" (without the spaces). We can't use that in practice, but it does show that there is no caching issue, and it's the ATE that suddenly has a problem with a specific set of characters.
This must be a problem on your end, in the ATE. Can you please check with a developer who worked on the last update of the ATE?
Please explain what kind of set of characters you use, since I can not reproduce it on your staging site or test site with simple text sentences, nor I am sure in which cases it happens.
Please go to your staging site, create a new test dummy page, translate it, and share the with me URL so I can see what happens.
As it works fine for me there and for simple text I used, it translates and save fine.
It is extremely strange. I even tried it from a different computer as a different user. No difference. This wasn't an issue before yesterday, using the same computers, users and website.
Anyway, on the staging site the problem also reproduces when a dummy page. Please go here, in the frontend first, and you can see it:
What do you need to know about the set of characters? We simply type u, o, a and characters like that with an umlaut directly on our keyboard: ü, ö, ä.
