WPML 2.9 is officially out with new features, fixes and enhancements that we’re sure you will love.
The language switcher section received a major overhaul in this version, making it a lot easier to build all sorts of language switchers.
Flags-only language switcher (without writing code)
We’ve enabled the option to display just flags and added an option to display list-style language switchers horizontally. Together, these two features let you create flag-only language switchers and display them as widgets.
In addition, WPML 2.9 improves the drag-and-drop language ordering.
The language switcher options page got a complete rewrite and it now covers everything that WPML can do.
Folder for the default language
WPML 2.9 lets you display the default language for your site in a language-folder. So, your site’s URLs can look like:
example.com/en/
example.com/es/
example.com/fr/
To enable, select the Use directory for default language option in the Language URL format box.
When you enable this option, you can choose what goes into the root directory. This can be either a WordPress page or a static HTML file. If you want the root page to look exactly like other pages in your site, a WordPress page will be fine. If you want it to look completely different, like the world’s map, you can create a static HTML file.
bbpress Compatibility Fix
This one kinda went under the radar for us. Since bbpress 2.3 was released, it became incompatible with WPML, in a very basic way. bbpress initialization order has changed, making it load before WPML loaded. This created a race condition, leading to bbpress menus to be hidden.
We had to rework WPML’s init sequence to adapt to this change. As a result, WPML and bbpress are fully compatible again.
Front-end Translation
We’ve been quietly working on a new way for you to translate sites – from front-end forms, and it’s ready now. Using CRED, our front-end content editing plugin, you will now be able to create forms for translating content from front-end pages.
You might be wondering what good is front-end translation. Good question!
When you create front-end translation forms, you have complete control over the translation interface. You can build these forms using a mix on HTML and shortcodes (for inputs). This way, you can style the translation interface to match the content.
For example, if you’re translating ‘houses’, you’ll write the labels and group fields so that it’s super-clear to the translator what each field means. This level of customization is only possible when you really know what you’re translating and what each field means.
Another advantage of front-end translation is that your translators don’t need to go into the WordPress admin. They see the familiar translation interface, right on the site’s public pages. Translators click on the + icons to add content or the ‘edit’ icons to edit them.
Using CRED Frontend Translation, your translators get the same privileges that you define in WPML’s Translation Management. You choose if translators can work in the WordPress backend, frontend pages or both.
To enjoy frontend translation capabilities for your site, you will need to buy CRED and have a CMS account for WPML. Then, download CRED Frontend Translation from your account and you’re good to go.
Other Changes
Along with these major changes, WPML 2.9 includes a list of smaller enhancements and fixes.
- Title tags added to navigation
- rel=canonical now optional configurable under WPML -> Languages → SEO Options
- Allow to select all languages when sending documents to translation from the Translation Dashboard
- Improved Import/export .po from String Translation screen
- Preserve url parameters in the language switcher
- Duplicate all custom fields and taxonomy when duplicating the post
- New function in the Troublshooting section to set update translaiton tables after changing the slug for custom posts or custom taxonomies that had translated elements.
- Allow re-assigning translation jobs
Bug fixes:
- Browser language redirect (some IE versions)
- Custom flag icons do not display on post table columns (posts screen)
- Slug translation in LS not working when WPML default language is different than ST original language
- Language order not applied before first drag
- Changing the slug of a taxonomy breaks things
- Wrong url for custom posts with translated slug.
Misc:
- Changed references to deprecated jQuery function live()
Next for WPML
Better Multilingual E-Commerce
Our next major milestone for WPML is actually not going into WPML, but into WooCommerce Multilingual. Like you probably read here already, we are completely rebuilding WooCommerce Multilingual. Our aim is to provide the best possible experience, running multilingual e-commerce sites.
In this spirit, the next minor WPML release will be dedicated to adding features that are needed for multilingual e-commerce. The major one is a centralized translation page for taxonomy. It will all become a lot clearer when we release the first beta of the new WooCommerce Multilingual plugin.
We’re talking about WooCommerce, but once it’s ready for WooCommerce, we’ll make that plugin generic to support also Jigoshop, MarketPress and possibly WPEC.
Complete Roles Management
Just like many of you, we’re growing here. Just a few years back, there were 3 of us doing everything. Now, we’re over 30 people and everything becomes more complex. Managing the translations for our different sites is one of the tasks that we want to streamline.
It would be great if we could have someone managing translations. Today, that someone needs to be a WordPress admin. It’s problematic.
For WPML 3.0, we plan to create a new role called ‘Translation Manager’. That manager will be able to send content to translation (posts, taxonomy, strings and products). They will be able to communicate with translators, raise issues and edit the translation.
If you too see a good use for a translation manager, add your comments here and tell us about how you see it working.
What do You Think?
Do you like the new features in WPML 2.9? Any suggestions or ideas?
We can’t implement everything immediately, but we’re very happy to hear from you and see what can go into upcoming releases. Leave your comments and let us know.
BTW, We’re Still Hiring
At the moment, we have openings for three developers. If you’re an outstanding developer, a fun person to work with and want to join a place that’s both a job and a family, please contact us.
Good news Amir, keep it up like this, we don’t expect nothing less from you guys! Thx…
Awesome update guys and very happy that bbPress once again is compatible!
Regarding the Translator Role that you are looking to introduce, I am actually of the opinion that it is far more important to create a Translator capability.
With a Role, you need to give a specific person that role which is only going to be very cumbersome. Making a Capability however will offer much more flexibility. Take for example Gravity Forms, they also have a bunch of different capabilities that site admins can use, for example in combination with the Members plugin (of Justin Tadlock).
I develop and manage a whole bunch of sites and for all those sites I am the webmaster and ultimately responsible for the running of the site. When I only have Gravity Forms installed, I just select the capabilities that the client needs and that’s that.
If I also have WPML installed then I need to add another plugin that selectively hides stuff for a certain role.
If you ultimately decide for a Role, then please please also introduce some capabilities that developers can use.
See forum entry: https://wpml.org/forums/topic/wpml-capabilities-2/
Definitely the right way of doing this. Simply creating a new role is so wrong and not nearly as flexible as giving new capabilities and permissions. I would much rather simply add a capability to a users cap list vs. having to change their actual role.
This becomes very important because as of yet, WordPress CANNOT assign multiple roles to a single user. That is exactly what capabilities are for, not roles.
Thanks for the input. We’re hearing this a lot. Let us go back to the design and see how we can do it better. I’ll write an update soon.
Hi guys. I’m having a problem updating to this new version. I tried in different websites and all have the same error: http://i.imgur.com/Oil8sYq.jpg?1
If you notice there is an “undifined” where it says “Plugin Information”, maybe the error is there?
Thank you.
I didn’t explain the error in my previous message.. The input field are disabled, I can’t write on them. I’m using Chrome.
Can you please post about this in our technical forum? We’ll get the right support person assign to the thread and can do this debug much more efficiently. Let me know the link to the forum thread, so that I can assign it to the right person. Thanks!
Sure, here it is: http://wpml.org/forums/topic/updating-to-2-9-error/
I really, really want to see a UI overhaul for WPML 3.0
You should assign this task to someone whose profession is UX. A developer “with a good sense of aesthetics” does not always nail it.
I can’t promise a complete rewrite, but let’s see where we should start. What admin screen troubles you the most?
WPML is a powerful plugin. A very powerful one. So, I understand if its admin screens got a bit crowded over time. But it doesn’t have to be so. I really can’t just say which screens trouble me the most because most of the time many of them do.
Especially where WPML inserts some UI/controls in general areas (e.g. post edit screen), not its own administration screens, because that’s what clients see.
I’m trying to be as fair as possible when I say:
1) You can ditch the dashboard widget
2) There are many “messed up” elements when backend language is RTL (e.g. Arabic). Small things like (float: left) that don’t convert to (float: right) contribute to a poor UI
3) Try to stick to WordPress look and feel as much as possible so as not to feel like a “plugin”. So, blue borders around languages and those colored icons break the experience, IMO
4) The stuff that WPML adds in Appearance > Menus need a bit of better aligning
5) The stuff (metabox) that WPML adds in taxonomy edit screen also needs more love and better integration with the rest of the page (e.g. same look and feel)
6) The bigger issue is the HUGE pile of options that are scattered across different admin screens. I can remember how many times I wanted to change some WPML options and I visited a couple of pages before I finally found what I was looking for. And I’m a developer.
7) Other stuff that I really don’t recall right now. But what companies usually do is hire a UX professional (or team) to re-imagine the look and usability of their software– just like how you would hire a security team to review your code.
I really hope to see some big aesthetics changes in the coming versions, and I hope I have provided a feedback that is as constructive as possible 🙂
Thanks for all your detailed feedback. Honestly, we haven’t paid enough attention to our admin RTL CSS. I’ll see what we can do about it.
Also, I agree with you about the dashboard widget. It’s not the most useful thing in the world. May be the opposite.
I’ve copied your entire comment and added to our issue handling. I’ll see what of it we can do for WPML 3.0. Some of these things are fairly simple and will certainly help.
One of the things that we’ve noted ourselves is the multitude of options on the ‘language switcher’ section. It just grew and grew and needs some re-design. My intention for that section is to separate between ‘which language switchers to show’ and ‘style the language switchers’.
Anyway, we have some great feedback here and we can start to work on it.
I too agree, that it is more logical to add specific translation managamnet permissions, which can than be assinged to any role, rather than a specific role for translation managers. I know, that your background is organizing a network of translators, but a lot of sites actually get translated from the same people, who add content to them and often the admins themselves,
For me the most reasonable feature request in connection with translations, however, remains the ability to give specific users aceess to editing posts in specific languages only. I knon, that this is a lot of work, but it will make managing corporate sites so much easier.
Yes, me too a new fresh UI 🙂
not too sure on the compatibility with bbPress; forum post: http://wpml.org/forums/topic/wpml-2-9-bbpress/
seems solved after some additional steps.
Is bbPress Multilingual 0.9 still needed now or not?
You shouldn’t need any glue plugin to run WPML and bbpress. We just fixed the initialization order, so that the two plugins can co-exist, as they are supposed to. A glue plugin may add additional functionality, but it shouldn’t be required to run bbpress basically.
Thanks for confirming that Amir.
WPML has many problem on multisite: it’s a pain to update and from version 2.6 it became impossible to translate the title and tagline for the subsite.
Please fix it 🙂
Cheers!
This is strange. We’re doing most of our QA on WordPress multisite and haven’t run into similar issues. Any chance that the trouble you’re getting is related with a theme, or with something else?
If you have a support ticket about it, please paste here the link, so that I can follow up. Please note that this is basic functionality and we’re testing it before any release. We’re not seeing such basic problems in our QA, so to help you, we would need to see it happening on your site.
Hi Amir, it’s Enrico here (I’m logged in now)
Here’s my original thread:
http://wpml.org/forums/topic/tagline-bug-with-wplm-2-6-x-and-wpmu-wpms/
Here’s another forum thread where Harshad says it’s a known issue:
http://wpml.org/forums/topic/site-title-multisite/ (I have the same exact issue)
Thanks for the forum links. I’ll follow up with Andreas and Harshad. From reading it, the issue seems to be related to MarketPress or the SEO plugin, but I can’t be sure. One of them (Andreas / Harshad) will need to install a complete similar setup and see what you’re seeing.
Except for the outstanding bug, unsolved since March 14 (!!) that makes it impossible to update from 2.6.2 (http://wpml.org/forums/topic/update-from-2-6-2-to-2-7-1-breaks-the-language-switcher/) I have one big wish for future releases:
Better performance!
WPML accounts for 80% of all plug-in response time (6.2s of the 7.8s average plugin time) according to the P3 plugin test when I tested it a little while back. (Running 36 other plugins.) It slows the site down substantially.
a HUGE +1 on this. There is no plugin that takes anywhere near the resources on my server that wpml takes. There just has to be a better way of doing the translation.
WPML includes various settings which may help you translate more easily, but take up server resources. These settings should be used when developing the site, but not necessarily when running it.
Have you read this?
http://wpml.org/2012/01/can-your-site-run-faster/
There’s a general section about page caching and then it explains different WPML settings.
my admin has a problem and compatibility problems
Warning: Cannot modify header information – headers already sent by (output started at /home/content/00/11140700/html/wp-content/plugins/wpml-string-translation/inc/slug-translation.php:601) in /home/content/00/11140700/html/wp-includes/pluggable.phpon line 876
Did you start a support thread about it in our forum? Obviously, this is a problem that doesn’t appear in every site that runs WPML, so our support team will need more information about which other plugins you’re running and the theme.
Very happy to read in the RLN that the language switcher now has a flags-only option.
Sad to notice that it doesn’t work as I would expect.
I have the switcher in my primary menu, with the zeeStyle theme.
If I turn off language names and leave only the flag option, both the flag and the (native) name remain in the menu bar, but the dropdown shows only the flag.
Also, if the dashboard preview for the flags-only switcher is reliable, the dropdown is way too wide to accomodate only those tiny flags, which is a waste of screen real estate.
Is the flags-only option a work-in-progress, or is there something else going on? Or are my expectations off?
We set it to include the language names in the menu bar. When we tested, flags-only appeared a bit weird (to us) in drop-down menus. So, we thought that you might want to display horizontal flags in a widget and have a drop-down name with texts in the WordPress menu. We’ll see if we can add even more options to make the content of the language switchers completely customizable.
More options would be great, but first things first: the combination of options I describe is flawed, because it does show flag and name in the menu bar, but when I open the menu, it displays only the flag of the other language (see this screen shot). It would be great to have a flags-only list in the menu bar instead of a dropdown, but I’d settle for a consistent dropdown… 🙂
FOR NON DISPLAYING A FLAG with the flags-only option, you could try this
Edit Languages Menu > put a Non-Breaking Space in the language name : ” ”
so far works in: Safari, Chrome, Firefox – macOS / safari for iPad / 😉
try this for NOT DISPLAYING a flag on the flags-only option:
use a non-breaking space in the Edit Language MENU: ” ”
for example > instead of English, put
so far so good for Safari, Firefox, Chrome (MacOS) / Safari on iPad /
Thanks for adding the default language folder.
I created 2 weeks ago a support ticket to solve this request, because I thought it works out of the box and now it is official supported, great!
You’re very welcome. I hope that it works well for you. Let us know if you need help with anything.
I’ve got a problem after an update from wpml 2.7.1 to 2.9 on wp 3.5.2: hidden languages remain hidden even for the admin (show hidden languages is checked in his profile).
I tryed to show&hide again each language (actually we have 5 languages setted up) but hidden langs stay hidden. Languages marked as not hidden works with no problems.
Am I missing something?
It’s a new issue that started after we had to change WPML’s init order, due to major changes in bbpress. We’re looking into this and will fix. Thanks for reminding.