Skip Navigation
13

A month ago we announced first betas of WPML 3.4 and WooCommerce Multilingual 3.8. Today, we’re after 4 weeks of intensive testing (and a number of fixes and improvements) and we’re happy to release these as production versions.

Like we wrote in the beta announcement post, these versions of WPML and WooCommerce Multilingual focus on much improved usability and translation workflow. This update makes it easy to work with multilingual WooCommerce sites, especially when using many WooCommerce extensions. The streamlined translation interface puts the different fields that extensions add in a convenient translation editor, side-by-side.

Download

This update of WPML is available directly in your WordPress admin. If your site is registered, you should receive the update notification in the Plugins admin screen within the next 12 hours (the time WordPress caches the status of updates). You can also download WPML manually from your account.

Coming Next (soon)

50% load reduction

In the past few weeks, we’ve also been busy analyzing the load that WPML adds, especially in the admin. We are thankful to all the clients who helped us with test sites. Most sites showed the issues that we were familiar with, but almost every site also showed us something else, that was new to us. The issues that we learned are related to content, server configuration and hosting environments.

We already found several improvements that will reduce execution time for most sites running WPML (including our). The highest impact of WPML was on listing admin screens, such as the WooCommerce Products page. There, we can reduce execution and SQL queries by about 1/2. On other admin screens, WPML’s contribution to load is a lot smaller, so the relative improvement is smaller (but it’s still significant compared to WPML’s part).

We’re going to push the performance improvements in two steps.

WPML 3.4.1 and WooCommerce Multilingual 3.8.1 (in about 2-3 weeks) will include a reduction of around 25% in execution time and 50% in queries to these listing pages.

WPML 3.5 will come with a completely new way we load strings to memory. Preliminary tests show that this new algorithm is very promising. It can make sites with WPML load even faster than sites that use compiled .mo files. The idea is to selectively pre-load only the strings needed for each page (front-end and admin). This way, we avoid both huge queries (to load all) and many tiny queries (to load many individual strings). Our tests show that this works even faster than the built-in “load_theme_textdomain()” and “load_plugin_textdomain()” calls. We’re aiming for a very significant improvement in CPU time, number of queries and memory.

Schedule for WPML 3.5 is still flexible. We’ll see how fast we can get a first beta and announce it.

Revamped language switcher

The language switcher in WPML 3.5 is a complete redesign. It’s 100% backward compatible, so all existing sites with work unchanged. However, it will offer new possibilities for language switchers, which we hope will make your work easier.

To name a few:

  • Ability to display different language switchers in different menus and widgets without limiting to one
  • Compatibility modes with different CSS frameworks, including Bootstrap and current WordPress default themes
  • Customization for colors and design per language switcher

I’ll write about it and include in a beta as soon as it’s available.

Translation for links in strings

We use strings for many different purposes. Many themes include complex texts in translatable stings and often also links. In WPML 3.5, all links in strings will automatically adjust to URLs in the right language. When you’re sending strings to translation, if these strings contain URLs, WPML will adjust the URLs in the translated strings.

For example, let’s suppose you’re using Gravity Forms and have a comment linking to a page (pretty common situation). You want to translate this comment and you’d want the comment to link to the correct page in the translated language.

When you translate the GF form, WPML converts the texts to strings and sends them to translate as a ‘Package’. The translator will need to translate just the texts. When translation is complete, WPML will scan all completed strings and check if they have links. If there’s a link, WPML will check if it goes to a page that’s been translated to the same language. If so, it will update the link to point to the translation.

This sounds easy, but is a pretty involved process. We need to handle translation in any order (no matter if you’ve translated strings before or after pages) and to keep accurate book-keeping.

Feedback?

Please let us know how you’re doing with WPML 3.4 and WooCommerce Multilingual 3.8. We’d love to get your feedback about the changes in this release, as well as the plans for the next rounds.

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

13 Responses to “WPML 3.4 and WooCommerce Multilingual 3.8 Released”

  1. Hi,

    This sounds like a huge work. Good job guys seems you are going in the right direction.

    By the way in case it helps, I’m one of those affected by WPML and WOOCOMMERCE with the bloody admin-ajax.php taking over 8seconds to load. BUT, i managed to reduce it from 8 seconds to 3 or 4 (so 50%) by adding this line of code to the functions php file of my theme (got it in child theme)

    add_action( ‘wp_enqueue_scripts’, ‘dequeue_woocommerce_cart_fragments’, 11); function dequeue_woocommerce_cart_fragments() { if (is_front_page()) wp_dequeue_script(‘wc-cart-fragments’); }

    Thanks
    Kind regards

    • Hello Andres,

      Thank you for your feedback!

      It would help to get some more details about the issue.

      Could you please create a thread in the support forum?
      There we will be able to ask you some more details and provide you with a better support.

      Thanks,
      Andrea

      • I alredy did and they where the ones sending me to this thread to read that you are working on it.. i guess i might miss understood but for what your text says in this blog, it seems to me that you already know about the issues between woocommerce and wpml… if you need more clues let me tell you the problem is with the string translations plugin from wpml and woocommerce with the admin-ajax.php. In fact if i dissable the string translation plugin (which in reallity i cant work my site with out it) the website loads fast as ffffffffffffffffffffffffffff

        • Andres, Andrea was referring to this support forum

          We did get your ticket on wordpress.org. Thanks for that too.

          However, on the official WPML support forum we have some additional tools that can help us debug this issue. You can send us a duplicator package and we’d look directly at your site to see what the problem could be.

          Especially if it’s something that we’re not aware of yet. Sometimes specific extensions, that we haven’t tested, interfere with our plugins.

          • Hi Mihai,

            With all respects, I hate when customer support does that. In this case i guess you did not understood my last answer on that thread, my bad, I’m spanish and I might not have explain myself properly.

            Dissabling strings tracking DOES improve the speed, but DOES NOT avoid the issues as you suggested. I recomend you guys taking a look at it on the duplicated copy of my site i sent you, that by doing so, and using the queue code I implemented in the Child theme functions.php (unoficial code) the site went from 8 seconds to 2.6 seconds. I beleive that a shop with 44 products can go faster, or a page with no images, just plain text should load faster, but this fragments thing is slowing down the website.

            I would love to hear from you guys soon telling us, the whole comunity you manage to speed up WPML and all its appended plugins (string translation, woocommerce, etc)

            Thanks
            Kind regards

        • Just to clarify. The ‘track where strings are used’ feature is intended ONLY for development and not for production sites.

          This feature will parse the PHP for every string and record where it’s used. This adds great information to strings, showing the context and usage. It helps translate sites accurately and avoid situations where a translator translates a string without understanding the context (like if it’s a verb or noun).

          It’s a very CPU-consuming feature, but also gives valuable information. You only need it when you develop the site. After you passed through these strings once, they all have usage information. You should turn this feature off and you’ll get the performance of your site back up.

          We’re also taking a note to highlight this feature in the UI and make sure that WPML tells you to turn it off for production sites.

          • Hi,

            It really changes the load speed, and im really happy you (all XD) pointed it out at me. But still the site is not faster enough, it is still runing in slow loads up, as it loads for every page something called cart fragments ?wc-ajax=get_refreshed_fragments which i understand part of the code is from the woocommerce, but the weird thing is that if i dissable string translation, this resource goes from 1.7 seconds to load to do not even load it up, which makes the site load in les than 1.5 seconds.

            As mentioned before, you can do the testing by using the duplicator copy of my site i sent you guys through George Botsev.

            Thanks
            Kind regards

  2. Hi,

    Just one thing to clarify this workaround should be only used on pages that don’t have cart widget, otherwise if page has cart widget and script is dequeued the widget content won’t be updated properly.

    Dequeuing cart fragments JS on front page will improve load time. Since it will remove AJAX call which takes long time, because of some performance issues especially with ST, which we are working to improve.
    WooCommerce needs this only on pages where cart widget is added, but it makes this call on all pages, because it has no way to know whether the cart widget is added on page or no.
    So it tries to get updated cart content and stores it in session storage if it’s available, to not make AJAX call in future on each page request.

    Thanks,
    Eduard