We’re ready with another, final, beta for WPML 3.8. Like you probably know, in this release we are focused on performance. Since the previous beta we found additional room for improvement and it’s ready for your testing now.
The new defaults for speed and ease-of-use
Until now, when you activated WPML’s String Translation, you had to configure it. This meant two things:
- Without configuration, translations are not showing.
- You could pick the “right” configuration or the “wrong” configuration, leading to low performance and harder use.
Now, when you activate String Translation, WPML automatically sets the best mode for your site. What’s the best mode? This depends on the actual strings found in your site. If you only have strings that come from English texts, WPML sets it as the site’s default. WPML will only run String Translation in other languages, so that it doesn’t slow your site for the default language.
Bottom line, there’s less configuration and better performance.
When you upgrade to WPML 3.8, it will check if your configuration has room for improvement and would suggest to you to automatically make changes when needed.
Run String Translation only when it’s absolutely needed
String Translation allows you to translate texts (strings) from one language to others. In WPML 3.8, we’ve applied several important speed optimizations to this:
- WPML doesn’t look for translations to the original language.
- WPML doesn’t check the original language of each string separately.
- WPML only loads the right strings needed for each page.
Together, this means much faster operation.
String Translation instead of .mo files
The major new feature in WPML 3.8 is the ability to replace .mo files with String Translation. You probably know that WordPress uses .mo files and that .mo files are relatively efficient (because they’re running below PHP).
However, this holds true only for small .mo files. Some plugins (and even WordPress core) have HUGE .mo files. WPML has huge .mo files. WooCommerce has huge .mo files and other plugins and themes also.
If it takes WPML longer to load the translation of “a string”, but it loads a tiny fraction of the strings found in the .mo files, WPML can do the job a lot faster. For example, when you’re looking at a blog post on the front-end, you need maybe 15 strings from WordPress core (“leave a reply”, “reply”, etc.). To get these few strings, WordPress loads a HUGE .mo file.
Now, WPML will block loading this .mo file and, instead, supply the translations for these specific strings. The performance gain is very significant.
For this little magic to happen, WPML needs a short training period. As soon as you activate the option to “not load .mo files”, WPML hooks to the .mo file loading and reads the strings that they contain. We do this in small batches, so as not to load your site too much. When this training is over (typically, after several loads of the site), WPML switches mode, blocks the scanned .mo files and supplies the necessary translations.
Give it a try!
WPML development team spent months on this version and we’re eager to know your feedback. We are running full QA next week. If you can test this version on your development sites, we’ll know for sure that all the new stuff doesn’t conflict with your code and with plugins and themes that you’re using.
To test, go to your WPML account and click on Downloads. Switch the channel to Beta and download. Make sure that you’re downloading all of WPML’s components that you use (you should not mix “production” and “beta” components).
Let us know how it’s working for you?