We’re ready with a beta for WPML 3.5. This release includes major improvements to String Translation, both in functionality and in performance.
Almost every site that uses WPML uses String Translation. So, you can imagine that making WPML’s String Translation better is very high on our priorities. This release of WPML is almost exclusively devoted to improving String Translation.
Faster and Leaner String Translation
In order to translate strings, WPML needs to load the translation from the database. We’ve experimented with different loading techniques and it looks like the approach in WPML 3.5 is the definite winner.
In previous releases we tried to:
- Only translations, exactly when they’re needed
- Pre-load all strings by context
- Pre-load all the strings from the database
Each of these approaches had its cons and pros. The problem was, for each site that benefited from one of these approaches, another site suffered.
WPML 3.5 uses a new approach to preloading string translations. It keeps an additional table, telling WPML which strings are needed for each page. Then, it preloads exactly the strings needed for that page, no matter which context they belong to. The obvious advantage to this is fewer strings preloaded and no strings need to be loaded while the page renders. As a result, both memory consumption and CPU utilization are way down. The downside of this new approach is tiny new PHP code that keeps track of which string is used where. That additional code runs very fast, due to dedicated DB access and caching that we developed for it.
The performance gain that you should expect depends on different factors:
- The number of strings in your site – the more strings you have, the greater the benefit (relatively, fewer strings pre-loaded now).
- The server’s PHP version – PHP 7 is way more efficient than PHP 5.6. If you’re still on PHP 5.x, you’ll get a much more significant performance boost, but you’ll feel it on PHP 7 too.
- The number of other plugins that you’re running, the amount of content, theme, etc. – obviously, if your site has other slow code, the improvement to String Translation is not going to be that significant.
For our own WPML.org Website, we get the following performance improvements:
| PHP version | Page | Memory consumption saving | CPU utilization saving |
|---|---|---|---|
| PHP 5.6 | Home | 60% | 41% |
| Admin dashboard | 41% | 33% | |
| PHP 7 | Home | 50% | 16% |
| Admin dashboard | 33% | 15% |
Translation for Links in Strings
The other major improvement in WPML 3.5 is the ability to translate links in strings (automatically). Why does this mean and why do you need it?
We use ‘strings’ for many different things. For example, if your theme stores the ‘lead’ text of your homepage in an ‘option’, WPML will use String Translation for it. Until now, you would need to keep track of strings that have URLs and adjust them to translated content manually. If many strings have links, this could be a very tiring task.
Now, WPML handles links in String Translation, the same as it handles links in ‘posts’ (posts, pages and custom types). When you translate any string that has any link, that link would automatically adjust to point to the translated content. I’ll write a separate blog post that shows how this works with our Toolset Layouts plugin.
Update Aug/2
Hey, we found another source of very significant time waste on the admin. This one is trivial and should have been handled a while back. There’s a “WPML widget” on the WordPress admin, which probably nobody needs anymore. That widget pulls content from many places in the DB, as well as recent blog posts from wpml.org Website. Removing this will eliminate a number of DB calls, as well as potentially slow external calls.
We’re taking care of that widget (removing it) and reviewing all external calls, to make sure they don’t slow down your site.
Download and Try
WPML 3.5 is going into QA now. We’ve already fully tested the change to String Translation, but there’s a lot more to test before we can release it as a production version.
We’d love to get your feedback about this new upcoming version. If your site has performance issues, related to String Translation, this version is for you.
Please remember that this is a beta version, so only try it on development sites (not on production sites).
This beta is only available to “Multilingual CMS” account holders, as it mainly revolves around improvements to String Translation.
Log in to your WPML account and click on Downloads. Scroll to the bottom and download the CMS Beta Package. Unzip and upload all the WPML components that you’re using to WordPress.
Feedback?
Let us know how this version is working for you by leaving comments here. If you’re running into a problem, start a new thread in WPML support forum AND leave a comment here with a brief description and a link to that thread.
We’re looking forward to your feedback, questions, ideas and suggestions!
So, finally you admit thr perforfance was bad.
Yes, performance for String Translation was slow. BTW, performance for the PHP GetText library is just as slow and for the exact same reason.
WPML’s String Translation and GetText did the same thing, which is to pre-load all the translations into memory. So, no matter how you would build a non-English WordPress site, you would get less-than-optimal performance for translating strings.
We’ve spent a great deal of effort analyzing and optimizing this process for WPML 3.5. Now, WPML will only load the string translations that are needed for each page, in each language. To the best of my knowledge, you will not find this functionality anywhere else.
For instance, take a large plugin like WooCommerce. When you run WooCommerce in a single non-English language, you get thousands of string translations loaded into memory, no matter what page you’re looking at. For any given page, you only need a tiny fraction of these strings.
WPML 3.5 will load exactly the necessary strings into memory. This makes string translation faster than previous WPML releases and even faster than the built in GetText calls.
I hope that this helps explain it. Please feel free to test and give us your feedback.
Thanks
That’s exactly what the logs showed
However, in my experience, when I moved from string translation to using the old mo/po files, it was a lot better, with the files that were exported with WPML. The difference was quite obvious
Did you try to implement caching plugin?
WPML works with caching plugins. Specifically, for String Translation, we make sure to be compatible with Object caching, which (when configured correctly) can help performance. Please note that you need to know how to configure object caching for it to give you positive results. It’s not trivial and pretty easy to get object caching to reduce performance.
To check which strings are used on different pages, we’ve added a dedicated DB table.
Two things:
1. It’s great that finally it’s being addressed to some degree
2. From what I saw, there was another performance hit from using lots of DB queries, with no clear reason. For example, when are in the Posts list page in the admin, the following query is used for each and every post id:
“SELECT language_code
FROM wp_icl_translations
WHERE element_id={{post_id}}
AND element_type=’post_post’
LIMIT 1”
for each post_id – why not all of them together? maybe it’s some kind of WP core architecture limitation, but you could try and fix this too. It matters in some cases
The same goes for posts that are queried for display
If it’s hard to work with the limited WP core hooks, then you can at least define some function of your own and instruct people and theme makers to use it. Lots of unnecessary queries can be saved
Simply do lots of posts in one bunch
And, another example, functions like “get_tags” – each tags is queried against the DB to find the translation. Why? it makes no sense
At least give some convenient way to improve it for those who do want to invest the time
I, as many others, have spent lots of time to understand why our simple sites are so slow when in admin mode. it’s like that for years and it’s a key ingredient. Tackle it, please!
Hi again, Amir
Could you please consider the issues I was trying to mention, maybe not so clearly?
“And, another example, functions like “get_tags” – each tags is queried against the DB to find the translation. Why? it makes no sense
At least give some convenient way to improve it for those who do want to invest the time
I, as many others, have spent lots of time to understand why our simple sites are so slow when in admin mode. it’s like that for years and it’s a key ingredient. Tackle it, please!”
There are many calls
Of course and it makes sense to check if we should and can cache these queries. In WPML 3.5, we’re handling a cluster of issues. We already improved String Translation, which will be a significant boost for most sites running WPML. We also got rid of the WPML Widget on the Dashboard, which contributed to a surprisingly large load, for no good reason. We’re going to release WPML 3.5 soon with these major improvements. Then, we’re continuing to other possible improvements. Thanks for bringing up the queries for taxonomy. I’ve already added it to our list of items to check.
I think that it’s better for everyone when we release gradual improvements. There’s no point in delaying this version because there are other possible optimizations. The major improvements to String Translation are already in QA. We’ll release this version, but don’t think that we’re stopping there.
Does this make sense?
it does. I just wished that the many topics about performance would have been get acknowledgements. It would have saved a lot of time and would build trust to just tell the truth.
People already realized that the string part is a performance killer, as I have realized
https://wpml.org/forums/topic/sticky-links-plugin-doesnt-function-properly-gets-wrong-id/page/3/
This issue was promised for v3.5, but I just installed the beta plugins and the issue is not resolved.
Additionally: “This thread is marked as fixed in next release. Support staff may not reply to more posts. If you need further assistance from our staff, please start a new thread.” is not really helpful if issues aren’t actually resolved.
I checked again and this issue appears to be tested and working in WPML 3.5 (beta).
So now, I’m checking to see if the fix is indeed included in the beta package and if it was tested on YOUR site. We did test it on a development site that we set up for this purpose. If the issue is in the beta package, works for us and not working for you, it would be great to get a Duplicator package of your site, for debug purposes. I’ve asked the supporters to request it, if needed.
Can you describe your test-scenario? I happens for me with pages that have the exact same URI, apart from the language string, with exactly the same titles.
FYI In https://wpml.org/forums/topic/sticky-links-plugin-doesnt-function-properly-gets-wrong-id/page/3/#post-908845 I highlighted the problem area (from what I could find out)
Will I be able to translate widgets (and its contents) with this update?
Today you should be able to translate most widgets already with WPML. If you are using custom widgets, which are not translatable, use this plugin to control their language:
https://wordpress.org/plugins/wpml-widgets/
I’ll give it a try, thanks!
Is there a roadmap available? Or when can we expect a stable 3.5?
We’re in QA now and planning to release WPML 3.5 in about 3 weeks.
Coming same taxonomy term slug for multiple languages?
I don’t think that this is technically possible in WordPress. In this release, we were mainly focused on the improvements to String Translation and a few minor bug fixes.
Actually Polylang Pro can do it.
I requested this in support forum before.
Sure. I’ll have another look and see.
I haven’t tried Polylang Pro by my own hand.
But It might use same term slug for all languages but between certain languages since they call it shared slug.
Does anything need to change for developers and plugins that are WPML compatible or can we continue using the same functions as we did in prior versions?
Nothing changes in WPML’s API. There are so many themes with compatibility for WPML, this sort of change would cause problems to thousands of sites and we’re making sure that all our internal changes are transparent for the API calls.