Skip Navigation
27

WPML 2.8.1 brings in long waited features and also series of bug fixes and refinaments.

Support Different Domains for Languages in WordPress Multisite

If you are running a large multisite network for your different websites, now you can assign different languages to different domains.

To do this, WPML comes with a new drop-in file for sunrise.php.
This is done with a drop in that’s included the new plugin release.
For complete details, read about Languages in Domains for WordPress Multisite Mode.

Mobile-Friendly Language Switcher

Until now, the only mobile-friendly language switcher for your site was the footer links (or if you build a custom language switcher). We’ve added a ‘mobile-friendly’ mode to WPML’s drop-down language switcher, opening it to visitors on tablets and phones.

The mobile-friendly language switcher looks exactly like the ordinary one. The difference is in the way it works. When you select a mobile-friendly language switcher, visitors click once to show the list of languages and twice to select their language. There is no ‘hover’ operation, which doesn’t exist on mobile devices.

You can enable the mobile version always, for mobile browsers (recommended), or never.

Allow logging in from on different domains

Up until now one could only log in on the domain corresponding to the default language while using the multiple domains options for language urls. The new version offers the possibility of logging in on each separated domain.

Drag-and-Drop Ordering for Languages

I hate it when languages move around in our footer for every language. There is some logic behind it, but it seems so un-logical.

WPML 2.8.1 includes a new interface that lets you drag languages and order them.

The ordering from this GUI will be the default language order for WPML’s language switchers. If you are using WPML’s API to build your own language switchers, you can choose between this ordering, language name or ID.

Languages Order

Correct Sources for WordPress Core Translations

This version of WPML changes the location from which WPML loads translations for WordPress. Instead of the old and abandoned SVN repo (don’t worry if you don’t know about it), translations are now coming, in real time, from the WordPress Translation project.

If this is new to you, you can read all about automatically downloading WordPress translations.

It’s the same GUI as before, but now, translations are coming from the best location.

WordPress Translation – importing translations (1)
WordPress Translation – importing translations (2)

Bugs Fixes and Tweaks

This new version brings beside the new features a series of bug fixes and refinements.

  • WPML Media – problems with duplicating attachements
  • Added a filter for _parse_wpml_config – allow setting translation properties to custom types, fields etc without using a wpml-config.xml file
  • Fixes for parsing wpml-config.xml for certain situations when multiple configuration files were present
  • Tags of secondary language get deleted when editing post
  • Translate by WPML option is disabled
  • Admin language as edit language is not working
  • Media Translation produces incorrect URLs in Windows
  • Warnings approving and replying to comments
  • Notices and Warnings when resettign a language
  • Translation Editor: Insert/edit link dialogue does not filter by page list by language

Updating WPML

As always, the recommended way to install and update WPML is by using our Installer plugin. Installer will let you get WPML updates directly to your WordPress admin.

You can always download WPML manually from your account.

Interested in WordPress 3.6 Support?

WPML 2.8.1 runs pretty well on the latest WordPress betas. There are a small glitches that we’re handling and we’ll be ready with an update for WordPress 3.6, before the new WordPress is released. If you try WPML 2.8.1 with WP 3.6 and see any issues, please report in our technical forum.

27 Responses to “WPML 2.8”

  1. Would you mind commenting on how your sunrise implementation is different and/or any better than the well known and well functioning (even in WPML configurations) Domain Mapping plugin? Why did you need to come up with your own?

    • Because, as far as we know, the Domain Mapping plugin redirects all the traffic for a child site to one domain. We had to change it to send different languages to different domains.

        • Hi Willem,

          With ‘Support Different Domains for Languages in WordPress Multisite’ you can have a multisite WordPress installation (different domains) and for each site have different language each using a different domain.

          e.g.

          – website A: http://www.domainA.com/ (nl translation: http://www.domainA.nl/, fr translation: http://www.domainA.fr/ etc…)
          – website B: http://www.domainB.com/ (nl translation: http://www.domainB.nl/, fr translation: http://www.domainB.fr/ etc…)
          – etc..

          • Hi, thanks! If I understand you correctly you are saying the exact thing I was asking right? The only difference is that not every domain needs translation like I showed in my example, I assume that is not a problem?

            Last question, the domain for a translation you can choose what ever you want right? For example, the ‘domainA’ part does not need to be the same for the original site and translated site.

            • Yes. If you have a network with different domains, you’ll be able to assign translations in other domains to some sites and leave others unchanged. You can enter any domain for any language.

      • Nope, you can have it setup so that each child site has its own mapped domain. I have one install with over 50 separate domain names and it works great. Of course not with wpml though. It would be nice someday to see both domain mapping plugin and wpml custom language domains working together nice.

  2. Thanks for your ongoing efforts, team!

    I’d like to see the next major release (maybe 3.0?) focusing mainly on aesthetics. Yes, aesthetics. WPML needs a revamped look. Functionality-wise, WPML is super duper– no doubt, but you need to polish that UI more folks.

    Amir, please tell me you have something in works for WPML UI like the one you apparently also have for Toolset plugins?

    • Hi

      Thank you for your quick reply.

      Here is the message that came up right after upgrading:

      Fatal error: Call to a member function get_current_language() on a non-object in /web/htdocs/www.tricromia.com/home/wp-content/themes/canvas/functions.php on line 109 Notice: ob_end_flush(): failed to delete buffer zlib output compression in /web/htdocs/www.tricromia.com/home/wp-includes/functions.php on line 2705

      Perhaps it would be helpful if I mentioned that I had a previous issue, as reported on the following ticket:

      http://wpml.org/forums/topic/cannot-add-new-menu-items/#post-119096

      Please contact me privately so I can give you admin access to my site.

      Thanks

  3. It would be nice to see a lot more time spent on woocommerce and wpml. Right now they work decently but are very hard to translate all the fields and other extensions for woocommerce.

    • I’m with you on this. Since we moved our own site to WooCommerce, we can see all these things a lot better. The next major development for WooCommerce Multilingual is to add a central management screen, where you can translate everything related to the store. This will include product attributes (all of them), taxonomy, variations and the store pages.

      Instead of a huge documentation page that explains how you should do things in 5 different admin screens, you’ll have one clear admin screen that lets you enter the translations and that’s it. We’re aiming for 2-3 weeks for this.

  4. Not sure if I should write this here or open a thread…
    Just upgraded to 2.8.1 and received the following:

    Warning: Invalid argument supplied for foreach() in –omitted–/plugins/sitepress-multilingual-cms/inc/translation-management/translation-management.class.php on line 918

    Warning: Cannot modify header information – headers already sent by (output started at –omitted–/plugins/sitepress-multilingual-cms/inc/translation-management/translation-management.class.php:918) in –omitted–/wp-includes/pluggable.php on line 876

    • I’ll look into this. From the forum thread, it’s difficult to tell what Bigul found as the problem and what needs fixing. Having this thread open for a month without any update from our side is certainly not a good thing.

    • I’m not sure that Adriano’s message in the forum is correct. As far as I know, these error messages are coming from GF’s .mo file. This means that you should be able to translate them either by getting an updated .mo from GF author, or through WPML’s String Translation. Have you tried that?

    • Hi Amir,

      I tried String Translations but those error messages show up nowhere in the String Translations overview. The .mo files seem correct; if I install Gravity Forms in a Dutch WP-version, the error messages are shown in the correct language. The problem occurs only if I use it in combination with WPML. I installed the latest version of WPML and Gravity Forms.

      Can you take a look for me? I can send you the login details of the test environment.

      Thnx,

      Taco

  5. Hi,

    when i try to get the automated translations for wordpress i get that there are more than 3800 files translated and when i hit the proceed button i get this:

    Request Entity Too Large

    The requested resource
    /wp-admin/admin.php
    does not allow request data with POST requests, or the amount of data provided in the request exceeds the capacity limit.

  6. Hey WPML!

    I’m a wpml+types developer, focusing on the hospo industry

    Any clues as to your what your e-commerce (+bookings) integrations and offerings will be?

    • Our little research, which started 3 weeks ago, shows that we’re dealing with quite a complex thing 🙂

      Toolset already includes good integration with e-commerce via WooCommerce. You can easily display products, add to cart and charge payment for forms. Connection all this together into a complete booking engine is turning out to be a complex thing. I’ll write a follow-up blog post with the results that we got in our poll. This may show you some solutions that others are using.

      Given the complexity of this, I don’t want to give an estimate for a timetable for our own solution. It’s too complex to estimate at this stage and will certainly not be available in the next few months.

    • Thanks. Im probably going to use the events+ from wpmudev (and they also have shcedule and a shop), i’ve got a couple of months so will hold back.

      Thanks for fast response!