WPML 3.2 is now done with all testing and is ready to run production sites. This week, we are still not pushing it as an automated update, but you can download manually from your WPML.org account. We are doing manual updates this week, so that you can choose where to upgrade and have more control over your sites.
Attention ICanLocalize clients
WPML 3.2 doesn’t support ICanLocalize. Please wait with your upgrade until version 3.2.1 is released. We are working to complete it ASAP. Then, WPML will arrive with automated updates.
The major new features in WPML 3.2 are listed in WPML 3.2 changelog entry. These include a new workflow for the Translation Management, new translation services, better taxonomy translation much improved performance and more.
Why Manual Updates?
WPML 3.2 include heavy rewrites of much of the code. It comes with new features, many fixes and a lot of overall improvements. In our testing, we tried to cover as many themes and plugins as we could. We are also running WPML 3.2 on our own sites and it’s all working smoothly.
We know that such a big update may have corner cases with different code. So, we have suspended the automatic updates and are encouraging clients to update manually. This way, if your site has any issues, we can help you faster.
How to Install WPML 3.2
Please log in to your WPML.org account and click on Downloads. Download all of WPML’s components that you are using. Go to your site, deactivate WPML and its components, delete and the upload again. You can see how to do this in this short clip:
Be sure to update all the components that you are using. You should not use a mixture of old and new WPML components.
Questions? Suggestions? Feedback?
Please leave your comments here and we will reply. If you need any technical help, create new threads in our technical support forum. All our team is trained on the new features of WPML 3.2 and will be happy to assist.
Thanks for the new update, but sadly I’m not seeing any performance improvements apart from my homepage loading faster. Actually from my early testing app performance is worse than before by a few seconds !!! 🙁
Check out these stats from new relic:
5.15 sec /single-product
5.05 sec /taxonomy-product_cat
2,940 ms /page
2,320 ms /404
23.7 ms /index.php
Compared to my current live build using the older version of WPML:
2,110 ms /single-product
2,020 ms /taxonomy-product_cat
1,970 ms /archive-product
1,870 ms /single
1,860 ms /archive
1,460 ms /page
1,200 ms /index
1,140 ms /404
857 ms /index.php
I provided you with dev access to my site when you were QA testing 3.2 so its disappointing to see these results… I’ll post this in the support area so that you can get one of the devs to have a look at what is causing this.
We’ll get your site backup and check why it’s happening. Do you remember the support thread you previously used or who you sent the site info before?
Hi Amir,
I had given access to Andrea. Shall I email him the details to our latest build?
Thanks,
Chris
Hello, will you enable the automatic updates?
Yes, we will enable again automatic updates. We want this version to come with manual updates for the next few days. Then, we’ll be auto-upgrading all sites with WPML.
Be aware that this version has deprecated support for strings default language other than English.
Don’t upgrade if you need this to function.
https://wpml.org/forums/topic/cant-set-default-language-in-string-translation/
Dear Raul,
That’s correct, but I must also clarify that support for non English strings was already removed in previous versions of String Translation: the difference is the option was still available (but not functional) due to an oversight.
As explained in the forum, the reason why we can’t allow to set other languages than English, is that strings are handled like any string in themes and plugins.
WordPress does the same: all strings (translated through GetText functions like `__()` or `_e()`, for instance) are considered to be in English.
This means that all WordPress strings, including any plugin you may have installed in your site, have strings in English.
This is the reason why we are stressing about using English in this in this post:
https://wpml.org/faq/string-translation-default-language-not-english/
Now, as we do understand that in some cases users may need to handle exceptions, we are working on a solution that allows to differentiate the default language for each string context.
The main reason of this is to allow creating non English strings for plugins that create contents in strings (for instance, Gravity Forms, where at the moment you must create the form in English, regardless it’s an active language, in order to be able to translate the form to your active languages).
But this also allows to deal with themes and plugins which strings are not written in English, even though this is against WordPress standards.
You must understand that this is not something that can be done in a matter of days, without causing potential issues: we need to work on this properly, run full tests, as well as quality assurance tests.
I can’t provide an estimation of when this will be released, but trust me that it’s among our main priorities to have this implemented, as we completely understand the need of it.
The recent changes in String Translation are all in preparation of this feature (an example is the Package Translation feature we recently added, in order to translate Gravity Forms, Layouts and other plugins contents as set of strings).
Thank you for your patience.
Thanks for your long reply.
I may explain why I used this feature and why it’s good for everyone who is developing their own products for their own use.
As a background. I’m not a native English speaker, nor my developers are.
I don’t want to show out to real customers any strings that developers create for obvious reasons.
To achieve it we marked all strings by default as Zulu language and then using WPML copywriter translated them to real English.
It enabled to take the strings out of the dev work-channel.
Maybe there’s some other way to achieve same result?
In addition to workload improvement it gave a edge on testing.
One can then use “pseudo-language” on all default strings, which helps to test the layout and responsiveness.
With pseudo-language you can add special letters in beginning and end of every string, so that you could very easily verify if everything is shown properly or not.
Like string “button” could be
“You must understand that this is not something that can be done in a matter of days, without causing potential issues: we need to work on this properly, run full tests, as well as quality assurance tests.”
Shouldn’t you have fixed this first before you depreciated the support of non English (custom) themes string translation?!?
You are right. But it was removed several months ago, not causing any problems. The problems were only when this function was enabled. We only removed the GUI now, for a function that was already gone.
Anyway, our next major feature for WPML is a complete update for String Translation. This will include complete support for different strings in different languages. The aim is to provide a much more convenient workflow for sites that use ‘not English’ as their default language.
Thx for your quick and clear response 🙂
(Y)
Waiting for it and happy to check out beta’s whenever their going to be “usable”.
OMG! All my WPML projects are now just trash. All of them have Spanish as primary language and my clients cannot create an English version of their sites!!! Is there any chance to have this option active again? Not by context but a global one… I’ll lose my job if I don’t have it!!
All your WPML projects will work after this update, exactly like they did before. The only difference is that we’ve removed an element from the GUI which didn’t do anything. That control for source language of strings was something that didn’t actually effect ANYTHING. So now, it’s also gone from the GUI.
Have you had any problem with any of your sites after this update?
So, If I’ve a project developed 100% in Spanish and Italian, what must I do to create a third English website? Edit all my php theme files and change all strings to English, then translate all this strings again via String Translation to Spanish and Italian? And what happens with widgets? I must create new widgets in English and translate them to Spanish and Italian?
Yes. This has been how WPML worked from day one. It’s not a new thing and it’s explained here:
https://wpml.org/faq/string-translation-default-language-not-english/
The reason for this is because WordPress itself includes all strings in English.
We are working on a major improvement to this in a nearby version. WPML will offer to set the source language per context and not to all strings together. Then, if you coded your theme with Spanish texts, you can choose that context and indicate (in WPML) that texts are in Spanish.
We are working on this and it’s not ready for testing. It’s a major new version and we’ll write about it as soon as there is a first test version.
Does this help?
So, if I have a site just in Spanish and Italian, I must say my client that he should pay for an English translation if he wants to use WPML?
Is there any estimated date for this feature?
FYI it has been a common issue in the forums for a while with people not being able to register WPML for automated updates. I think this video on how to properly perform a manual update might have solved the issue for me, as I have been able to register WPML and toolset plugins finally!
Previously I wasn’t deactivated and deleting wpml plugins before I was just merging and replacing the updated files. Just thought you would like to know as this can solve a lot of issues on wp-types and WPML forums.
Hi! I have the same issue. My whole site is messed up..
How can I downgrade to 3.2.? Just overwrite the FTP files?
Please open a support thread and one of our supporters will handle it immediately:
https://wpml.org/forums/forum/english-support/