WPML 4.6.8 allows you to easily review translations of content belonging to languages you have hidden. It also brings some usability improvements and fixes a handful of bugs.
Simplified Review Process for Hidden Languages
Working with hidden languages allows you to prepare and review translations for your content before making them available on the front-end.
Previously, you needed to enable an option that allowed users to review translations for hidden languages. WPML 4.6.8 removes the need for you to configure these additional user profile settings.
Now, your site admins, Translation Managers, and users added as a Translator can review translations for hidden languages right away.
Native WordPress Editor for Specific Translations
A consistent translation workflow makes it easier to manage your multilingual WordPress website and reduces the risk of overwriting or losing translations. But, it can be hard to remember how you created and translated different types of content, especially on large sites.
To help you maintain translation consistency, WPML 4.6.8 defaults to the native WordPress editor for certain translation types. This includes imported translations and pages linked using the Connect with translations feature.
If you use professional translation services to translate your site’s content, clicking to edit the translations will open the Classic Translation Editor.
More Improvements and Fixes
WPML 4.6.8 introduces a new option to the migration wizard that allows you to mark your original site as an independent copy.
By default, when you move your site to a new URL, WPML automatically restricts adding or editing translations on the old URL. The newly introduced option allows you to use the Advanced Translation Editor and automatic translation features on both the new and old site URLs.
This version of WPML additionally fixes issues related to:
- An incorrect number of translation jobs displaying as in progress when all translations have actually been completed
- The Preview not showing unsaved changes to a post or page
WPML 4.6.8 also resolves other bugs and glitches.
How to Update to WPML 4.6.8
As with all versions, we are releasing WPML 4.6.8 out in batches. If you want to update to it before it reaches your site, you can go to Plugins → Add New and click the Commercial tab. Then, hit the Check for updates button.
Don’t see the WPML update in your WordPress admin? Learn more about the gradual rollout process for WPML plugins.
Thoughts and Feedback
What do you think about the latest features and improvements in WPML 4.6.8? Which one will make the biggest difference to you? We’re eager to hear your feedback, thoughts, or any questions you might have.
Need technical support? Please contact our support team for a quick way to get help with troubleshooting.
I wish that editing professional translations would open the Advanced Translation Editor in stead of the Classic Editor. I know that would require sending and receiving text in sentences as translation units. It would make it so much easier to manage minor changes, because at the moment, when you edit even a small thing in the original translation, the classic editor drops the entire existing translation. I already submitted this as a feature request right when the ATE was introduced, but so far no change here. Unfortunately.
Hi! I understand what you mean, but unfortunately, that’s not something we can actually implement. The thing is, when you send something to a professional translation service, the translations are processed through a different system than the ones for Advanced Translation Editor (ATE). For example, the translation memory (which keeps track of content you already translated) is in your case on the side of the professional translation service and we don’t have access to it. In other words, it’s not possible for both ATE and a translation service to have access to the same content, its data, and all its metadata (e.g. what is the language of the translation, when was something translated, does it need an update, who translated it, which segments were translated, etc.). If we mixed the translators and translation editors it would be impossible for us to keep the status of translations in sync.
P.S. Please also note that if you use the Classic Translation Editor or the WordPress editor itself to edit translations that were done by a professional translation service, they will be overwritten the next time you send the same page/post to them for translation. And again, the reason for this lies in what I described above.
Thanks for your reply Dario! Although it’s not possible now, with software anything is possible, it only needs to be created.
1) The export that goes to a translation service can easily be formatted in the same sentence bases segments as the ATE does. Most translation agencies will even prefer that over a large chunk of text.
2) When the translation comes back, it could be fed into the ATE, just like it is when I manually update translation in the ATE.
Translation Memory: I know that translation services have their own translation memory, but that is irrelevant. All that matters is that their translations are fed into the the TM of the ATE, so that it is available when I edit a translation. You never need the translation services TM at all.
The metadata is available in the XLIFF file when it comes back, so when that XLIFF file is fed into the ATE, it can update it’s meta data accordingly.
I don’t see the problem of mixing the translation source and keeping track of the status. WPML already does it in the classic editor, so why won’t it be able to do it with the ATE?
I know that with the classic editor existing translations get overwritten when you send them to an agencies again. That’s the whole purpose of sending it for retranslation again. The same thing would be acceptable for the ATE.
In stead of looking for problems, you could also look for possibilities and solutions. The classic editor has issues but it doesn’t get much attention because the ATE is the way forward. So why not think about how you can streamline the whole thing around the ATE in stead of the old classic way?
Hi, thank you for a detailed reply. I asked the development team leader for more information and he explained that the technologies on our side are different compared to translation services. Also, WPML is integrated with a lot of translation services and each of them has its own system of doing the translations.
So, yes, anything can be done in software, however, this would be a huge project to undertake. Also, there are very few WPML users that need this feature and there are other things that a lot of WPML users need and are asking for.
Thanks, but I don’t see how the technology of translation services and the number of connected services is relevant. Nothing has to change for them, they keep receiving, translating and sending xliff as usual. The only change for them is that the content of the xliff file has to de sentence based, which is basically how it is supposed to be. So it will only get better for them and their translation memory.
The only change would be a process to get the professional translations into the ATE, either
– translation service » WordPress » ATE or
– translation service » ATE » WordPress
I don’t think that’s such a huge project. Certainly not as huge as the introduction of the ATE.
You don’t know if not many users need it, they just don’t ask for it, because most users never think about how it can be improved. I would say that everybody who uses a translation service could use it, because when you make a minor change, you don’t want to spend money on a service to get the entire page translated all over again. I mean, a translation memory is kind of a trade secret and most agencies let you pay all over again. Also, translation memory based on classic editor is bad because it doesn’t use sentence based segments. Is sends a large segment containing many sentences. If only one sentence changes, the entire segment needs to be re-translated, not just the one sentence.
Hi. I am sorry, but I really don’t have anything more to share than I already have. I know it sounds easy or straightforward to do but it really isn’t. And it was considered and discussed by the whole team and management in the past (not just now when you raised the question), it wasn’t an idea we dismissed easily. Also, imagine us needing to make 100+ translation services adjust the way their system works with translations and translation memory. All of them have their own timelines, roadmaps, and agendas.
Lastly, I don’t know which translation service you use, but the best ones should allow you to have a translation glossary (so you can tell them upfront how to translate certain words and phrases) and a way for you to tell them if anything requires improvements (and this is often free but depends on the service).
Sorry, but it looks like you are complicating the whole thing.
You keep referring to 100+ translation services that need to adjust their system, but with my proposal they don’t need to change anything!!!
All they do is translate segments contained in xliff files and t doesn’t matter to them if a segment contains a whole page, a paragraph, a sentence or a single word.
So my first proposal is to use the same segmentation rules that are used by the ATE, stick them in the xliff file and send and receive the files as usual.
The second proposal is to allow me to edit the translations inside the ATE instead of in the Classic Editor. That might take a bit more work to make it possible, but it can’t be that difficult either.
Can you please have a fresh and open look at this? I’d love to hear the possible challenges your team sees. I am happy to discuss this further in a phone or video call.
—
This is not about editing/improving a translation because the translation was wrong. It’s about editing a translation after changes in the source language.
Example: I make websites for restaurants. When they change the prices on the menu, it also needs to be changed in all languages.
* A translation agency re-translates the entire content and charge for it. If they use a Translation Memory they may give a discount, but there is still a fee.
* Doing it manually in the the classic editor is a mess. It usually drops the entire existing translation, so you have to copy & paste the original translation and then manually change the prices.
* The ATE is a winner. It just keeps the original translation and changes the prices automatically.
Thanks
JP
Hi! Thank you for your clarification, I understand your point. I will share your feedback with the developers to give it a fresh perspective. That being said, I cannot promise anything because we plan projects according to priorities.
Thank you, I appreciate that. The Advanced Translation Editor is awesome and I really would like to benefit from it, even when translations were originally done by professionals. If it helps, I am open for a chat about it. Thanks.
There are some deprecated messages when upgraded to PHP v 8.2
Deprecated: Creation of dynamic property Whip_RequirementsChecker::$configuration is deprecated in /home/a/public_html/wp-content/plugins/sitepress-multilingual-cms/vendor/yoast/whip/src/Whip_RequirementsChecker.php on line 37
Deprecated: Creation of dynamic property Whip_RequirementsChecker::$messageManager is deprecated in /home/a/public_html/wp-content/plugins/sitepress-multilingual-cms/vendor/yoast/whip/src/Whip_RequirementsChecker.php on line 38
Hi Ahmed,
Thank you for letting us know. I have passed your comment on to our development team, who has into this compatibility issue and created an errata that provides a temporary workaround to this issue.
If you experience any other problems, please do not hesitate to open a ticket in our Support forum – our team will be able to look into your issue and help you.