Do you enjoy searching for WordPress translations and installing them in your sites? If not so much, you’re going to like WPML 2.6.0. We’ve added automatic download for WordPress core translations. It’s in beta and you’re welcome to test.

When you run a multilingual site, you need to translate content, but that’s not all. Some of the texts come from the theme, some from plugins and some from WordPress itself.

While your theme and most plugins usually comes with .mo files that give you the translations you need, WordPress doesn’t. You need to look for these .mo files, download and install them.

Then, when WordPress upgrades, you have to repeat this process.

WPML 2.6.0 lets you forget about translation files for WordPress. It will download them for you and keep them updated when WordPress updates. As an extra bonus, you can forget about WordPress .mo files altogether. We’re saving the translations in WPML’s String Translation table. This means, that you don’t even need to make that cryptic ‘languages’ directory writable, or create it.

How WPML 2.6.0 Gets Translations

We’ve written a (fairly complex) script that scans the entire WordPress translations repository. The structure of that repository “not so consistent” (to put it nicely), but we don’t care. We read it and learn where translations for different languages exist. Our script creates an XML directory that we’ve stored on our CDN (content delivery network), for super-fast access.

WPML 2.6.0 will load that XML file when it needs to get WordPress translations. This include first-time install, new languages or WordPress updates. You can also tell WPML to check manually.

Go to WPML->Theme and plugins localization. You’ll notice a new option for “Select how to get translations for WordPress core”. When you set it to “WPML will automatically download translations for WordPress”, WPML takes over.

WordPress core translation downloader

Once enabled, you’ll see three new columns in the languages list. The first column tells you when you last got translation for that language. The next column tells which translations are available. The last column includes the actual download buttons.

Click on Review changes and update for each of the languages.

WPML Downloads the Best Matching Translation for Each Language

WPML will download the best .mo file for your WordPress version and the selected locale. For example, if you’re using WordPress 3.4.1 and need translation for Argentine Spanish, WPML will look for a locale ‘es_AR’. If it cannot find it, it looks for the default Spanish locale (es_ES).

Then, WPML looks for the best matching WordPress version. If it can find a translation branch for what you’re running, it gets it. Otherwise, it tries the ‘trunk’ version. Finally, it looks for the most recent version.

WPML Shows You What’s New or Updated

After WPML downloads the .mo file with the updated translation, it lets you review it before applying these new translations.

Confirmation screen before updating translations

Normally, you’ll just go to the bottom of this page and update the translations. If, for some reason, you want to keep back some changes, you can un-select specific strings. You’ll see both updated and new translations.

Finally, Translations Appear in WPML’s String Translation

Once you’ve approved the new translations, they appear in WPML’s String Translation screen.

WordPress translation in WPML’s String Translation

Since we’re saving these translations to the database, there’s no more need to create a ‘translations’ directory and save WordPress .mo files there. WordPress translations will be saved just like any other translation for your site.

In case you’re wondering, there’s no performance change. WPML loads all these translations in one SQL query and looks them up efficiently. It’s not faster or slower than using .mo files.

Of course, there are plenty of advantages to having these translations in WPML’s String Translation tables. For example, you can edit them and they are included in any DB backup that you do.

Download and Try

To get this download, go to your WPML account and click on Downloads. You need the recent Beta version. Download and unzip it. The plugins that have changed are WPML core and the String Translation plugin. You need them both for this new feature (yes, this means that translation auto-download is only available for WPML CMS version, which includes the String Translation module).

Please don’t run this on production sites yet. If you’re just setting up a development site, it should be fine. This version of WPML is fresh out of the oven. We ran a bunch of development tests on it, but it didn’t go through our production QA.

What do you think? Let us know in your comments!

7 Responses to “Auto-Download for WordPress Translations”

  1. “you can forget about WordPress .mo files altogether. We’re saving the translations in WPML’s String Translation table.”
    “WPML loads all these translations in one SQL query and looks them up efficiently”

    Rhis is not the current behaviour (WPML runs an SQL query for each string): did you change it with this new version?

    If this is the case, well, this would solve a performance issue I had and that forced me to disable String Translations and at the same time would allows me to uninstall another plugin I was using to get always the last WP .po/.mo files.

    • WPML loads all the strings with the same context in one SQL query. It stores them in memory, just like GetText does. If you have many strings with different contexts, you’ll see different SQL queries for each context. Again, this is exactly like GetText does. It loads a .mo file, for a given context, in one go.

      It’s been like that for over a year and there’s no configuration option to bypass that caching mechanism. You might be seeing other SQL queries, that are due to other features of WPML, including auto-string registration, etc.

      • Amir,

        Mine was supposed to be just a clarification request about this new feature and now I see that something’s wrong in the way my issue has been handled.

        I had 2000+ queries in my site that went down to about 140-160 (60, when I’m not logged as Admin) as soon as I’ve disabled String Translations.

        Even supposing that the site has many different contexts, each one is most likely related to a plugin or a theme, but I don’t have so many plugins and themes installed.

        There is an open ticket about this issue and so far the only solution is to disable this plugin.
        If this is not the right behaviour, why nobody from WPML told me that?
        For the way the issue has been “solved”, I had the belief that String Translations caching “normal” behaviour is to run a query for each string (and with some debugging, is what actually happens, as the “where” in each query contains the string and the context, not just the context).
        Now it seems that the issue is something or somewhere else, but nobody told me that in the forum.

        This issue caused me quite some issue with my provider and I had to pay for a VPS in order to have my site “isolated” from the others, to give some relief to the server that was hosting these sites.
        This moving costed me money.
        Luckily I’ve found the issue and disabled the guilty plugin, so next month I can move my site back to the old server and avoid spending money for someone’s else fault.

        I didn’t want to discuss my specific issue here, as there is a forum for that, so if you prefer to keep talking about that from the forum or by email, feel free to do it.

  2. What does it mean when the option to update is greyed out, file not found, and both WP Translation says “not available”?