Polylang 1.7 will not introduce a lot of new features but will focus on fixing several old glitches. These were generally quite minor issues, but hopefully solving them will improve the user experience.

I want to make Polylang working out of the box in most cases and avoid conflicts with themes and other plugins as much as possible. As part of this policy, setting the language from the content will be no more the default option. This will be made possible thanks to the new possibility to set the language code from the url when using default permalinks.

I am always looking for ways to improve the performance. Thus, the default flags supplied by Polylang will be base64 encoded, then removing one http request per language on websites using flags.

The code is regularly cleaned. Polylang 1.7 will require WordPress 3.8 or older.

You can download Polylang 1.7 beta and report bugs on the support forum.

For a long time now, Polylang attempts to download the WordPress translations files when a new language is added. That should work pretty well for all translations available on the WordPress svn repository. However, the update management was far from being perfect. It fired only just after a WordPress update and so could not work if the new translations files were not available at that time.

Also, now that the WordPress translations are managed on http://translate.wordpress.org/, less translators update their translations on the svn repository and thus, Polylang cannot find translations to download.

Fortunately, WordPress 4.0 introduced a new way to install and update translation files, called language packs. The main goal of Polylang 1.6 will be to take profit of this new WordPress feature to manage multiple language packs. Thus the translation files will be updated in a much clever way and will work for all language packs managed by the WordPress team.

Polylang 1.6 also introduces a few other features such as the possibility to translate a text widget in the strings translations panel (up to now you needed to use one widget per language), the support of opengraph language and translations metadata for websites running Jetpack or WordPress SEO.

As usual, I need you to test this new version, so don’t hesitate to download Polylang 1.6 beta1, test it and report bugs in the support forum.

My initial plans were to release Polylang 1.5 today. However, I made quite a lot of changes (code cleaning and several bugfixes) in the past days, and thus prefer to have more testing time and delay the release by a few days.

Compared to the initial beta release, Icomoon icons have been replaced by dashicons (for WordPress 3.8 and later) for better user interface consistency. As it would have been code consuming to maintain the compatibility with both Twenty Fourteen 1.0 and 1.1, I decided to support only the latest.

Download the latest Polylang development version

Polylang 1.4 introduced a new metabox with a dropdown list to show available posts (instead of post ids) to choose translations. I believe that this change was quite welcome as it was easier to use and I guess users having not too much untranslated posts are happy with it.

This however introduced a major issue for big websites. The metabox does not scale for a site having ten of thousands posts. And for these sites, it is just impossible to use Polylang 1.4.x. Even if such big websites are probably rare , I cannot let them stuck to Polylang 1.3.1.

I thus decided to rework the metabox again and replace the dropdown list (currently displaying *all* available posts) by an autocomplete input field (just like the one you are already familiar with to get post tags). The same kind of autocomplete input field replaces the old dropdown list to choose translations of categories and post tags.

This version also comes will less visible improvements such as better error management on Polylang admin pages and better compatibility with object cache plugins.

Download Polylang 1.5 beta