Skip Navigation
92

We just released a maintenance update of WPML, which improves compatibility, stability, and performance. But the exciting news is what’s coming. See what’s new today, what’s coming soon and give us your feedback.

WPML 4.2.7.1 News

Translation for Re-Usable Blocks

Reusable Blocks, as their name implies, allow to create an element in Gutenberg (the Block Editor) and use it again in other pages. WordPress smartly saves Reusable Blocks as custom types, so they’re separate from the content where they were originally created.

Now, WPML makes it easy to translate Reusable Blocks. When you use the WPML’s Translation Management, the Reusable Blocks will go to translation together with the content that includes them (if you haven’t translated them before). When you’re translating manually, WPML will show you a reminder on how to translate these blocks.

Any User with “edit_posts” Permission can be a Translation Manager

Until now, WPML only allowed admins and editors to act as the site’s Translation Managers. Now, if you create custom roles and assign them this permission, you can make them your Translation Managers. This is important because larger sites typically setup their own custom user roles. Now, when your custom roles allow users to edit posts, you can allow them to manage translations.

String Translation Performance Improvements

We’ve identified a number of queries that String Translation can avoid. Per call, this is not a lot, but on sites that load thousands of strings, it builds up.

String Translation in this release works faster. However, the upcoming release will completely change the way WPML’s String Translation works and reduce its load to virtually zero.

Fixes

We’ve fixed a number of nagging bugs in this release. The highlights are:

  • Fixed exceptions occurring when translating nested blocks.
  • Resolved an issue when translating the List Block.
  • Resolved an exception causing wrong redirects when having slugs containing only numeric characters.
  • Resolved an exception in handling multiple occurrences of the same field in an Elementor node.
  • Fixed an issue where Editor/ Shop Manager cannot duplicate a post (this should have been fixed earlier, and got delayed due to an internal workflow problem that we resolved).

Plans for the Next Weeks and Months

We’re working on major changes to WPML, which we hope will make it easier to run multilingual sites and make those sites a lot faster. See what’s planned and give us your feedback, so that we know that we’re building what you need.

Zero-Load String Translation (planned for mid July 2019)

We’re changing the way String Translation works so that it will stop hooking to GetText functions. The idea is to compile the translations into .mo files instead of loading translations from the database.

It looks like this change will reduce the database and CPU load of WPML String Translation to about zero.

We want to make sure that the new String Translation doesn’t cause any slowness for any site. If today’s String Translation is contributing to significant processing time to your site and you’re willing to give us a copy, please open a support ticket that starts with “Test site for String Translation performance”. Our supporters will take the copy of your site and we’ll use it as part of our testing and benchmarks during development.

“Translate Everything” Mode

We reviewed hundreds of client sites and we’ve noticed that almost everything on these sites requires translation. However, today, in order to translate such sites you need to go through multiple admin screens and select different items for translation (posts, taxonomy, strings, etc.).

To make your work a lot easier and avoid wasting your time, we’re working on a new mode that we call “Translate Everything”. In this mode, you don’t need to choose anything. WPML will send everything in your site for translation.

This mode will have two options:

  • To translate everything initially (when you install WPML)
  • To keep translating new content, as it becomes available

Our aim in this is to make it easier for you to have fully multilingual sites over time, without spending much time managing it.

Automatic Translation with Human Review

We still believe that professional human translation is the best way to have excellent content in all of your site’s languages. We use professional translation for our own sites. However, we also know that professional translation can be expensive and it’s not the ideal solution for all websites.

We’re working on new translation modes that will greatly reduce the time it takes to translate content yourself.

  • Automatic translation with human review
  • Automatic translation without review

In the first option, any time you send content for translation, it will get translated automatically. Then, this content will wait for a human review before publishing it.

In the second option, there’s no wait. WPML will publish the automatic translation for you. Of course, you can always click and edit these translations later.

From our testing, automatic translation with human review speeds up the translation dramatically. A page that takes me an hour to translate, I can review and polish in a few minutes. That’s over 90% saving for my time. And, because I went over the entire translation, I get great results.

We’re coming to WordCamp Europe in Berlin!

Last, but not least, this week we will be in Berlin for this year’s WordCamp Europe.

Are you coming? You can find us at the WPML table and we’ll be happy to talk!

See you there!

Feedback? Ideas? Suggestions?

Like you already know us, these are not the only features we’re working on. Of course, we’re handling all known bugs and we’re working on smaller features in every release.

If you could give us feedback about these major features, it will help us deliver better what you need. Leave your comments and we’ll get back to you.

How can we make WPML better for you?

Share your thoughts and comments about our plugin, documentation, or videos by booking a Zoom call with Agnes, our Client Advocate. Your feedback matters and helps us improve.

Book a call with Agnes

92 Responses to “WPML 4.2.7.1 and a Preview for Next Major Updates”

    • It should be ready around the middle of July. It will cover all the cases that we have for testing. If you have any site that’s working slowly due to ST, it would be great to get a test copy from you. Then, we can make sure that we cover what’s happening for you as well.

      • Hi Amir
        Supplying mine that I’ve had many support tickets opened for because of very slow page speeds when also using Woo. “Sorted” for a while (clearing cashes, deleting 30-40.000 strings), but it always slows down again. Turned off TS on one site just to be able to work with it in the backend. Then turn it on when I don’t have to. Off course the front end is broken when I turn it off.

        This looks very promising.

        Hope you sort the fact that all strings from a plugin you add are added to the ST database even it you tell it not to. Might be less of a problem now but the DB gets huge with 50-60.000 string in it!

        • Would we be able to get a copy of your site for testing? We keep these test sites very confidential and private without access to anyone external.

  1. Hello, when can we update to the new version? I’ve been deactivated for months with String Translation because it slowed down my web x10.

    I hope that this is solved because I was not using the plugin because my website was very very slow. regards

    • It’s planned for the middle of July. If you can give us a copy of your site, we’ll make sure that nothing remains slow for you as well.

      • Thanks for answering. But if I download and activate today’s version, will the web speed up? Or recommend waiting in mid-July?

        • The version that we released today includes several improvements, some also related to performance. We always recommend clients to use the recent version of our plugin. In July, we’re planning a more significant performance improvement, specifically for String Translation.

  2. Ok thanks. In addition to updating to the latest version I will wait for the version for string translations, because as I say, I have it disabled because the web loads 10 times slower. regards

  3. I am always reluctant and very nervous about WPML updates. Last year a major update introduced load and loads of bugs, we are still trying to get WPML to fix a final couple now. And then major changes in the way it operates confuses and annoy customers like the “required” Translation Management plugin which adds so much complication. I am considering never updating it once we get a stable version.

  4. Oh th’at is a good way ! The performances of website are very important and impacted by WPML. This performance update is what I was expecting.

    About “Translate Everything” Mode, these translations will be collect in WPML server ?
    You will save (in your database) all translations for all website who use WPML and re-use these translations for websites who need ?
    The software Poedit do that, and it really work !
    I would be happy that this is set up, it can be very helfull to translate all “technical” and admin content.

    • The “Translate Everything” mode that we are referring to does not store anything on our server. We’ve noticed that most sites translate all their content. So we want to make it easier for you to translate all your content, without having to go through multiple admin screens to choose what to translate.

  5. Here is an issue in existence since upgrading to the last major WPML issue.
    https://wpml.org/forums/topic/swatches-still-not-working-for-language-pages/ -> Closed by WPML but its NOT fixed! I have sent access to WPML loads of times so you have access as per the last comment

    Sales reports also giving wrong data. Have no idea why WPML wants to change values in sales reports:
    https://wpml.org/forums/topic/woocommerce-sales-reports-not-correct-with-woocommerce-multilingual-enabled/

    We also have a new ticket open about how to NOT use WPML Translation Management plugin with WooCommerce because we do not want the added additional complications this plugin brings, as we do not use multiple translators, we do not want translated status, all we want is to see the normal WP edit page like we used to. But we need it else things break:
    https://wpml.org/forums/topic/woocommerce-multilingual-is-enabled-but-not-effective-it-requires-wpml-translat-5/

    So with Translation Manager enabled we seem to miss some fields. Especially in DIVI, we have image fields missing so we cannot use it. The following thread is regarding the body that was missing and some work around we had to do to bring it back, but we should not have to do that, and we have other fields missing like I said:
    https://wpml.org/forums/topic/string-translation-results-in-fields-like-body-missing-in-some-products/

    This is REALLY old even before the last major update https://wpml.org/forums/topic/wpml-woocommerce-category-translation-not-copying-html/

  6. We have had many many more issues and tickets following the last major update. I think you need to put some beta release in place to people who opt in for beta testing and then months later ites like ours who just cant afford to lose ales due to WPML issues, can update when a table release comes out. I have not opted in to be a tester and fix issues.

    There is another issue on GitHub which I had to fix in the plugin myself, and I don’t know if its been fixed in WPML as no one told me, so we dont update that plugin: https://github.com/woocommerce/woocommerce/issues/21599

    • Is this issue related to WPML? Seems like it’s an issue that you reported for WooCommerce plugin, related with image zooms and cache plugins. I could not find any mention for WPML throughout the description of that issue on the WooCommerce bug tracker.

      • Oh yeah you are right sorry. Ignore that one. Nearly all of our problems on the site are WPML related, so I just made an immediate but wrong connection sorry!

  7. Thanks. I would be happy to see an option to use the string translation without the main WPML CMS or at least add option of “String translations mode”. This will reduce load & problems when i only want to use wpml for translations & not to add languages.

      • Loco translate indeed compiles .mo files. WPML is also going to apply string translations via .mo files, so it will be similar in that respect. WPML does a few other functions though 🙂

        • @Amir my comment was a question for @Ahrale

          Means, I think:

          Ahrale wishes a function similar to Loco Translate: only translate existing Strings, without the need to add languages. So a “lite” variant of WPML: just translate what’s already there in .po/.pot files, without the option to add something new.

    • The current release is already available to download from your WPML account. The next release will be ready around the middle of July.

      • @Amir

        The copy of our site, which I could send for performance analyses (ZIP including Wp + DB dump)?

        • Hi Adrian, the best way to share with us your site for debugging is to submit a support ticket here: https://wpml.org/forums/forum/english-support/ and from there our supporters will help you prepare the package for us and guide you through the process. If you have any issues with that please leave me a message here and I’ll help you.

          Thanks!

  8. +1 for simplifying things. I use WPML because it’s the most used WP translation tool and also supported by many translation agencies. At the same time, it’s way too complicated to get everything right.

    How will the ‘Translate everything’ and ‘Automatic translation with human review’ work together? Will all sentences of the entire be sent to a the translation manager in a single screen? Or will that remain page by page?

    Suggestion 1: I like the simplicity of Transposh where site owners can translate directly on a published page. That plugin has it’s own issues though, but such functionality in WPML would be awesome.

    Suggestion 2: Store all translations in a translation memory in the website database. I have experienced a lot of issues because WPML completly lost existing translations after the source content was slightly changed (translations created by a translation service and WPML using the classic translation method).

    • Hi John-Pierre and thanks for the feedback! Currently, we are working on the first phase for the ‘Translate Everything’ feature, basically, this will work as it does today – together with our Advanced Translation Editor (ATE) the plan is it’ll function the same way as we do today
      A translation job per language and per post, page, CPT or package –> ATE will pre-fill all the translations (with Machine Translation) and the translator (or site owner) will review and validate the translations, the review, in this case, means that whoever is responsible for the site’s translations will have to manually click on “Deliver” on ATE.

      We will also add an option to later synchronize the translations, so if you have that turned on and have enough words quota any time you update your original language content the translations will get updated.

      I hope that answer your doubts, if not we are happy to continue the chat.

      • Hi Amit, thanks for explaining. I think I don’t understand what the difference is going to be if keeps on working just like today. If I have 10 pages, I still have to go to 10 times to the ATE for review.

        To explain why I asked this, I use the ‘food and drink menu’ plugin a lot to create restaurant menu’s. It uses a CPT for the menu items where each menu item is a post. Basically only a title and sometimes a short description, but in the end everything is published onto a single webpage. Example here: https://www.joesburger.nl/en/menu/ You see 6 starters, and for each of them I’ll have to go to the ATE, which takes a lot of time. It would be so much easier and faster if you could send everything in a single batch to the ATE.

        • This makes sense. Right now, we don’t have something like this implemented, but we’re taking a note so that we know what you need from us.

      • Well thanks John-Pierre for your note > suggestion 1. I didn’t know Transposh but Weglot offers the exact same service, but with a to sharp pricing level.

        what I would say here is that Transposh shows that it shouldn’t be so hard to “ajaxify” the translation process, and this is all what we need. The actual backend work is pure hassle compared to it.
        And while I already mentioned that kind of improvement to WPML I find that it’s quite ridiculous to see how slowly WPML evolved over time. I am only in the WordPress world since 1-2 years but I expected far easier tools, really.

        So Amit, I thank you for your clear answer, but do you also understand that the approach you are talking about is far from what we suggest here ? And far from the pleasure of repeating myself, this feature shouldn’t be so complex to implement, it’s essentially a front-end ajax popup that display all those strings. It will probably be a bit more tricky for page builders, but I think that the biggest part of the work is already behind this subject.

        Finally, using such a technique it would help us spend literally 10X !!! less time on translation and forget about all needless strings.

        Waiting to read your comprehensive answer in the actual WPML’s line to make “effective” changes in 2019.

        • Yes, we definitely understand and we know how different plugins work. What Transposh and Weglot do is great, but doesn’t it really cover everything that you need?

          For example, how would you translate the content of emails? How would you translate error messages that you need to display on the front-end?

          This is besides the point that translation-proxy plugins don’t save your translation in your own database. If you disconnect from their server, you actually lose your content. That’s a pretty significant trade-off.

          • You’re right Amir, and thanks for this first internal reply about this important subject.

            Concerning Transposh I don’t know how they work, but for Weglot they use indeed an external server which I don’t like as much as owning my translations. And being able to translate internal texts is often as important.

            More-over, what I “suggested” then, is to enable an exact similar frontend translation UX using an Ajax approach. You might imagine adding a “start translating” button in the top bar when on frontend.
            All those translation would obviously be related to registered strings. Above that, for some badly written plugins it would be awesome to force the text recognition by one or other way if any is possible. Doing this would make WPML a real 360° solution.

            Only to repeat what everyone here accepts, please make the backend easier – offering a front-end experience would really fix the excessive translation time by 10X. So can I ask your team to think now on an effective technical way to achieve this. We would be So many to thank you.

            • Yup. We are planning to make the backend easier. The “translate everything” mode that I mentioned in this post is exactly for this. Today you need to go to multiple locations in the backend to choose different texts for translation. This is important for huge sites like our. We have a lot of text and we’re not translating everything. However, for 99% of our client sites, this is just hassle. Most clients need to translate everything on their sites. The “translation everything” mode aims to take care of this problem. You will need to translate the texts, but you will not need to visit multiple admin screens to select them. There’s no planned GUI for that mode. That’s the whole idea. Does this make more sense now?

              • All right, let’s wait for that release and see if any front-end GUI shall still be needed.

                Thanks for your clear answers, and see you later on this topic 😉

                Regards.

    • Thanks for the invite! We actually do have really good folks in Greece so I’ll pass that to them 🙂

  9. Hi Amir,
    I’m no more using String Translation, it was slowing too much our website.
    WPML is also not working properly with Fusion Builder, the Avada’s theme built-in editor: the existing translations are overwritten when the original page is modified.
    I’ve already opened assistance tickets, but up to now it’s only been a waste of time, a real nightmare.
    Will this update fix the issue?

    • We need to improve the way WPML works with Fusion. The problem is that Fusion doesn’t have global IDs for blocks. So when a block changes, it’s very difficult to connect it again with the translation that you previously did for that block. We talked with them about it, but we’ll remind them about it. Thanks for bringing this up.

      • Thanks for your reply.
        Some of our website pages were created with Avada’s Fusion Builder, then translated with WPML. What’s your suggestion how to modify the pages without getting overwritten translations?

        • For now, I’m not sure that there’s such an option. The best way would be to quickly update the translations after you’ve edited the original.

          • When I update the page, the translations are overwritten by the new english text, so I should rewrite the translations of the whole page 🙁
            No other ways?

            • I know that it’s pretty frustrating. We have a similar situation on one of our sites and I’m not enjoying it. But yes, when you update the original, you should send it again to translation, because the translations for the previous content will no longer show. Again, this is something that we should improve with Avada team. They know about it, but we probably didn’t press enough to get it handled until now.

              • Me again. I think that I was talking about something else than what you’re describing. I checked and our developers worked on a fix to a problem that sounds exactly like you’re describing. Marine will contact you and offer a patch that you can use until a new release is ready with this fix.

  10. AMAZING update folks! I am entirely dependant on WPML as it is the only plugin that allows me to translate everything, frontend and backend. My only issue has been the speed so grinding the impact of wpml down to 0 is HUGE. I’ve just been translating the wordpress dashboard and unfortunately the core file for wordpress which governs strings such as ‘publish’ save draft etc are not in wpml as is, so I have to use Poedit for that. The issue with this being that I am on a vps which Poedit cannot keep a connection to so when I update the translations have to be reuploaded. It would be super awesome if all of wordpress’ dashboard could be translated with WPML 🙂

  11. We’re changing the way String Translation works so that it will stop hooking to GetText functions. The idea is to compile the translations into .mo files instead of loading translations from the database.

    It looks like this change will reduce the database and CPU load of WPML String Translation to about zero.

    Of course?? How come you have not handled it with .mo and .po before? It’s a no-brainer for me. Of course, is slow if you lookup on every query.. and query the database on every request. This is how other string translation plugins like locotranslate, polylang, etc have done for ages.

    Facepalm wpml..

    • Actually, it’s a little less obvious than it appears to be. When we first built the current String Translation mechanism, it was efficient and fast. There were only a few WordPress plugins with tens of thousands of strings and they accessed them sparsely. So, WPML with ST was actually faster than loading large .mo files.

      Recently, plugin authors have become more “liberal” in the way they access strings and call GetText functions. Very liberal. As a result, a page that displays maybe 50 strings can hit GetText for over 50K strings. This turned things around for us. WPML caches and preloads these translations. When the .mo files were large but plugins didn’t touch all these strings, our preloading mechanism saved a lot of execution time. Now that a number of large plugins hit almost all their strings while render only a few, this preloading is counter-productive.

      So, instead of complaining, we’re updating our own mechanism.

  12. Hi, i can’t see the comments of this post, but i see only the counter : they have 52 comments.
    Can i see all comments ? Because it can be very interresting see what user can think about that. And talk about a issue with this update, if other have the same isssues like me.
    have a nice day

  13. These are great news and I hope to see any improvement in site speed for visitors. WPML is an essential plugin set for multilingual sites but it slows down so much the site in terms of visitor experience. To recover some speed I have disabled Translation Management and prevented css and js from loading.

  14. I am very happy to hear that there will be a new update. I like WPML and I think it can be a very good product when many of these problems are fixed. My website became very slow after installing WPML. I had to find other plugins to try to make the website faster. But the website is still very slow. I’m a bit afraid since I’ve read the comments about problems when installing a new update. I hope you work hard for to get a god product, so we don’t get even more problems with updates.

    It can be very helpful if you also send documentation on how to work with the new update and what to do to get the right settings in the program.

  15. That’s good news. The sites of my clients with WPML are very slow.If i disabled the translate string it’s faster, but the site intern linking don’t work anymore so I have switch to Translatepress. I hope you solve this. Why now after all those years?

  16. I create unique content for each new language on my site. The translated pages are separate from the originals, sometimes with different layout etc. and I update them manually. I do not use Translation Management (I have deactivated it) because I find it unhelpful for my needs. I only install Multilingual CMS and String Translation.

    Please can you say whether the new mode will affect me? Will it be possible to opt out of “Translate Everything” mode?

    • Your workflow sounds fine. If you are translating yourself and you want to design each translation manually, you don’t need the Translation Management plugin.

      The planned “Translate Everything” mode is optional. If you don’t want to translate everything (like we are not translating everything for our site), you don’t have to use it.

      Does this help?

  17. Zero load string is a must, I can’t update posts, with Visual Composer my server goes down. I need to deactivate all WPML plugins, update the content and then activate plugins again.

    • Sergio, thank you for joining this discussion. I insist that the upcoming release of WPML will work smoothly on your site. To make sure that we’re not overlooking anything, either Amit or Igor from our team will contact you. We’ll need a copy of your site, so that we can check why it’s slow. Would that be possible?

      • That would be great, I even doubled my hosting cost to get more power and even so, it goes down. Just let me know how I could help, if you need a copy just explain me how to do it.

      • Thanks a lot for your help on this Igor, I have been dealing with web server problems for long time, after your suggestion about switching to a new hosting provider my website is rock solid, much faster and even cheaper. I’m really happy, top support!

  18. Hello, have you a beta test of the new version of String translation now ? It can be a real pleasure to test and help you for this big improvement.
    I can make many dev website.

    have a nice day

    • We are almost ready. First, we are going to run it on our own production website, see that everything is good and that performance improves a lot and then we will release for clients to download. We should be ready with the public download in about a week from now.

  19. Hello, do you know when the new version of string translation will come out? I hope soon, I have it disabled because it makes my website too slow and heavy

    • We should have a beta version in about a week. First we are going to run it on our sites (wpml.org, toolset.com, icanlocalize.com) and see results and then we will publish for clients.

      I want to make sure that our improvements cover the cases in your site. Can you please create a support ticket, show us your site and show where you are seeing the performance problems? Our supporters will ask for a copy of your site and try it locally to verify that the new version handles all performance issues.

      After you open this support ticket, please add another message here with the link to that ticket.

      Thanks!