With WPML 2.3.4 out, we’re starting work on WPML 2.4.0. As always, we have more ideas for features than time to build them, so I’d like to hear your voice before we choose what’s in and what’s out.
First, the “big picture”. Our goal is to make it easier for you to build multilingual websites. I know that this is pretty obvious, but we need to always keep that in mind. The big question is, what are you actually doing, and so, how can we make your life easier?
WordPress is moving farther away from blogs and into mainstream CMS. As such, we see these parts becoming critical:
- The menu system – any WordPress theme that we see already uses the native WordPress menu system. Often, a site includes several menus, replacing hard-coded texts and other custom-solutions.
- Custom data types – the combination of custom post types, taxonomy and field lets webmasters build anything using WordPress. We see more need for better integration with custom write panels.
- Role management – complex sites have multiple authors and a hierarchy of admins. This calls for more fine-grained access control, including per language.
For WPML 2.4.0, I’d like to see major improvements on these three fronts. Let me tell you what we’re planning.
Auto-Synchronize Menu Translation
Already today, you can translate menus with WPML. The hard part is actually creating these translated menus in the WordPress Admin. Although possible, this may be a major challenge for admins. If your menu includes dozens of items and you’re running a site in 3 languages, you need to manually recreate that menu three times. Of course, if you don’t speak those languages, it’s a bit more difficult.
In WPML 2.4.0, I’d like to see a synchronize menu button, for each menu. This will automatically create translations for that menu in all other languages. Once the translated menus already exist, it will update them to reflect changes in the default-language menu. This way, any manual edits that you do on translated menus will be kept.
Support Custom-Field Synching with Custom Write Panels
This one is a tough nut. There are several great custom-field management plugins, which produce a great user-experience when working with custom data. Unfortunately, WPML cannot properly synchronize custom fields between translations when you use these plugins. This is because all these plugins go around the WordPress API and create their own conventions.
We’re working on a commercial-grade custom-field plugin for WordPress and we expect to release it in a few weeks. This will allow to completely customize edit panels, while being fully WPML-compatible. This will be a free plugin, downloadable from the wp.org repository. We see this as a complementary function to WPML, and a very necessary one.
Integration With Role Scoper
Many users have already requested that WPML and Role Scoper work correctly together. The RS author is also interested in that and so are we. The only thing missing was time. It’s already included in the todos for WPML 2.4.0.
Once this is working, admins will be able to choose what different users can do. This includes access to WPML’s admin screens as well as access to standard WordPress functions, based on language. This is all preliminary work and depends heavily on third-party cooperation.
What do you think?
I can’t promise that we will include everything that you suggest, at least not in WPML 2.4.0, but it’s very important for us to hear it. If you have comments about what we’re planning or great suggestions about what we should add, leave a comment. Thanks!
The roadmap is very exciting — great work! Big thumbs up for integration with Role Scoper!
My vote goes to synchronization of menus.
In Belgium we have 3 official languages, so any advance in making wordpress better as a multilingual CMS is a great step forward for us !
Can’t wait for the new features !
My vote also goes to Auto-Synchronize Menu Translation. Here in Brazil we are developing many sites using 3 languages (pt_BR, en and es). So everything to make things easier is more than welcome.
Great stuff on the roadmap. Pity (for me) that you have chosen Role Scoper instead of Justin Tadlock’s Members plugin for the role management, I guess I will have to change to Role Scoper too then…
Menu synchronisation will also be a favorite for me! Perhaps a good idea to keep in mind that a menu should first be complete in one language before synchronising it with the other language(s). And if something is added to/deleted from the menu of the default language, to keep the synchronisation in place and working.
Synching with Custom Write Panels would also be a fantastic new feature! Perhaps integration with Rilwis’ Metabox class is an idea? More info on http://www.deluxeblogtips.com/meta-box-script-for-wordpress/
If I can I would also like to suggest to plan an update/refreshment on the WPML documentation. A lot of things have and are changing and I get the feeling that there are quite some people that don’t have a clue how to properly set up WPML.
I know that almost every function of WPML is documented somewhere, but the difficulty is that it is not so easy to find everything on the wpml website; it’s a bit scattered around in my opinion.
I just finished a WPML consulting job where this was the case, especially the Custom Fields Translation table under the Multilingual Content Setup tab of Translation Management is unclear at best. And if people forget to change things there, WPML just doesn’t work properly.
Regarding the Media Module I think the process of scanning for images should be something that happens standard. I know that it shows a box with the suggestion, but I find that many people just don’t understand this. So perhaps it is an idea to automatically scan and duplicate all images after installation of the Media Module?
For the rest, great work as usual! 🙂
Great suggestions, as always.
For our documentation, what do you have in mind? I tried to organize it as ‘getting started’ and a collection of questions to frequently asked questions. How would you see it more sensibly?
Hi Amir, apologies for the late reply, I was away for a few days.
I didn’t have sth specific in mind regarding the documentation, but since you ask, I might as well give a few suggestions.
Foremost I think that it would be very helpful if all documentation is organised together, more streamlined. Looking at your Getting Started Guide, the beginning indeed is there, but a lot of links go to other parts of the site instead of staying in a clear and concise guide.
As an example I stick to the Media Module. In the Getting Started Guide I cannot find anything about it. Then under the tab documentation on your website, the only place that has a sentence on the Media Module is “WPML Core and Add-on Plugins”, but there are no further links whatsoever. Only a search on the site gives links to the Media Module where the link to your blog has all the information on how to go ahead on that.
I think it would make more sense to copy that very useful information over to the Getting Started Guide or Documentation tab as new people will look there first to start with WPML.
I do realise that a documentation overhaul is not the most pleasurable work to put energy in, but on the other hand it might save you a lot of time answering questions in the forum too.
Hope this helps a bit and feel free to ask me for more details.
Agree with first comment that your road map is very exciting. You seem to have a good handle on what is needed, and only have two comments at this stage:
(1) Further support for e-commerce needs whatever that might be! You are already likely on top of this with custom posts, but just a reminder just in case it isn’t. WordPress is digging into the CMS are very strongly as you say, and e-commerce is related to this.
(2) Agree that documentation needs more work. I know there is plenty already there, but I think adding screencast type videos supporting your docs and showing setup and answering most questions would be very effective. You can then refer to videos in your support forum which seems to have so many basic issues that clear docs would help save us all time.
Also, some very simple answers to basic questions like Q: What are the advantages and disadvantages of selecting WPML to do translation, versus using language (.mo) files? (That Q bugs me a lot and assume WPML translation is perfectly Ok.)
(3) Talking of WPML help, the string translation would be even better if we could identify widgets and other string areas more clearly. Maybe in the docs already, and perhaps I should ask question on forum? 🙂
Anyway. Keep up the very high quality work you guys are doing. I might even find some time to make some tutorial videos myself, if only to run them past you and see if I actually understand what I am doing with WPML. 🙂
I cannot stress enough the time I spent on the custom menus for my site, which is only in 3 languages (I speak them all). It still took too long to get it working, especially when you are dealing with 200+ static pages.
I would say that the Auto-Synchronize Menu Translation is the most important feature (at least for me) that I would really really really really love to see in the next update.
Especially considering the fact that I intend to add 3-4 more languages to my site, all of which I don’t speak *yikes*.
This is exactly how I see it too. We’ll release beta versions as soon as we have it working and I hope that folks will test that it does what they imagine it should. We’re already working on the menu sync and I hope to have a working beta in about a week.
Role Management would be great. At the moment i have to give my authors admin access ,, not something im entirely confortable with at all so if i could vote twice I would. The other thing would be displaying the base language if no translation exists outside the loop.
David
My Vote is for Auto-Synchronize Menu Translation
It would also be cool if WPML would have some support for the Yoast SEO plug-in, especially somehow be able to provide different blog titles and descriptions for each language.
Right now, the homepage in all my languages has the same title 🙁
WP SEO actually has a configuration file for WPML. You should be able to translate these strings in WPML’s String Translation screen.
Ah, sorry about that, silly me 🙂
I would really like the option to turn OFF the automatic splitting of comments per language.
And maybe a better integration with the WPML Media plugin? This doesn’t work very smoothly for me sometimes…
Other than that: great plugin! Saved me a lot of work!
MENUS MENUS MENUS MENUS – how many more votes do you need:) With good integration WPML is a killer (many of us here are not coders)..
I vote for the menu-synching as well as priority one. The other features you are working on is great as well. Especially the roles. Yesterday we added Chinese to the languages on our site, and I had to grant Admin-access to the translator to do the strings. Not very happy about that because the translator working on it has no clue about WP. I just hole she does not delete something by accident.
Yup, that’s coming along nicely and will be the first completed version in the next beta version. We should have solid code to release for testing in about 2 weeks.
These three features are all great, but I’d like to propose another. Translation-sharing. Part of the ease of WPML is that you can translate plugins and themes into different languages. This is especially handy if and when the plugin/theme doesn’t come with the appropriate mo/po files for your languages. So, using WPML, we translate them. But just for our own site(s). Why not share those translations via WPML and thus help plugin/theme developers and designers to improve their i18n.
Something along the lines of this:
– translate theme/plugin
– export translation
– send to WPML
– peer review/waiting for final approval
– send to developer for inclusion into wp.org package
– rejoice
Whaddayathink?
We thought about doing this and even wrote about it, but soon realized that it’s not the best place for such an initiative. For plugins and themes on WP.org, the better place is the WordPress translation project, which seems to be picking pace now.
If not already in WPML, I’d like to see pages and posts that are not translated display with the default language, whilst awaiting a translation. I’d also like to see category pages show default posts for non-translated pages.
I Completely agree with this. I Think this is the biggest limitation of WPML that makes impossible to use it in many projects. Hope this will be implemented soon.
I’m surprised nobody else mentions this (or maybe I simply have not read something somewhere), but I’m uber-desperate for a decent integration with the wp touch plugin. I’ve asked on their forums as well and the answer on both sides seems to be that there is vague interest, but no specific plans.
That’s a pity since both plugins are, in my opinion, extremely powerful extensions that greatly amplify the appeal of any wordpress site, and thus a combination would be good.
Christian.
We just don’t know what is missing. Can you explain?
I’ll get back to you on that once we’ve done our redesign; it might be correlated to the fact that the current theme we use does not support custom menus. (And yes, I’m aware I can create on and just use it for WP_touch … I’ll see how that works.)
And by the way, I really like WPML! Especially the media sub-plugin has proved very valuable already again!
Auto-Synchronize Menu Translation will be great !
About a new Custom-Field Synching with Custom Write Panels module, I’ll prefer a collaboration on an existing plugin because better custom field modules take advantage of their tier collaboraboration with other modules or webservices.
A collaboration/donation on this new function will offer not only a larger customer base for the plugin development, more contributions and less dev. efforts, but also more visibility to WPML.
The key point is to find the relevant partner, due to our analysis, you have probably take a look to existing plugins.
About role, it isn’t a priority for me ….
A better documentation, a wiki? is a priority.
My second idea is a child theme, with some page template and functions able to help us to take advantage of wpml code in our templates …
twentyeleven is a very popular theme and will be a great choice for the community.
A svn or git with this content for theme developers will help them to adopt WPML.
My third idea is to take advantage of translations already made by our members, most of plugin developers will be interested by this content.and will contribute to improve the internationalization. RPC exists and most of us will be happy to share our translation efforts.
Thanks again for your amazing job,
I’ll be happy to offer to you an endorsement if you have a linkedin account.
Feel free to connect: http://fr.linkedin.com/in/frenchsalesconsultant
Laurent J.V. Dubois
Same slug across langugaes would be great insted of adding numbers!
/de/projectname
/fr/projectname
Thanks!
Aldo
Yup, this is high on my wishlist too.
WordPress 3.3 is supposed to make big improvements on URL resolution and I hope that it will be possible then.
Please prioritize Role management. As we have a site with many authors, and a few editors. it would be extremely helpful if they could be able to assign translation-jobs themselves, without me as an admin being the only one with the capability of doing this.
As said before, being able to assign users to specific languages would be really useful.
Hi guys, how to make WPML working on domain mapping? Yesterday we thought it was working and we activate a new website but we’re KO with the second language!!!
The WPML works on the multi-site, but not with the domain mapping…
It should be just a .htaccess feature I think, isn’t it?
I don’t know. We didn’t manage much with Domain Mapping. Some users say that it works for them, but we are having a hard time with Domain Mapping without WPML.
Some months before i tried to use WPML on a multisite network with Domain Mapping… the result was not so greate.
Now…. it works just great. I’ve tested it with a 3-Site-Network and 4 languages with different primary domains and every thing works like a charm. Even the subdir-language-control …/en/… or …/fr/… works as expecting.
I’m not sure but i thing it was one of the last changes the guys from Domain Mapping Plugin did
I don’t know how old or new this info is but here is a smal excerpt from the DM site:
Thanks for letting me know. So, it probably works now because of incremental improvements in compatibility in both WPML and Domain Mapping. Our current version of WPML has new URL decoding logic, which narrows down the language attributes much more accurately. This probably plays nice with the new logic in Domain Mapping.
My Vote goes to improving performance