Polylang 1.8.1 is a maintenance release. The main goal is to fix a regression introduced in version 1.8 concerning secondary queries with translatable post types and non translatable taxonomies. It also fixes a few other minor bugs that I noticed while testing during the last week.

Facebook and WordPress introduced a lot of new locales during the past year. I updated accordingly the mapping between these locales used for Opengraph support when Polylang is used in conjunction with Yoast SEO or Jetpack.

Three new translations have been moved to languages packs (ca, de_DE and pt_BR). And a brand new translation was created (es_CL). Today, already 16 languages packs are available for Polylang. 27 older translations are still supplied with the plugin. Thanks a lot to the translators and translation editors for their work.

Share this:

Like this:

After almost two months of beta tests, Polylang 1.8 has just been released.

As described in an earlier post, the most visible changes are in the plugin settings pages which have been totally revamped.

You are now able to choose your own flags for the languages, directly from the admin screen when adding or editing a language. The default language is now identified in the languages list table and can be modified directly in the table.

Since the last update, six new WordPress languages packs (ary, bn_BD, en_ZA, es_AR, fr_BE, fr_CA) have been created. These languages found their place in the predefined list.

The settings are now arranged in modules. One late change not earlier described is a new option to allow Polylang data not to be deleted when the plugin is uninstalled. If you want to delete all Polylang data when using the red “Delete” link in the plugins list table, you now have to check this option in the Tools module of Polylang settings. This option is unchecked by default.

The hreflang html tag now contains the locale instead of the ISO-639-1 language code. This will allow users having several variants of the same ISO-639-1 language to have valid W3C locales in the hreflang tags. Polylang also works around an issue in WordPress for non W3C valid locales (ex: de_DE_formal).

I also worked on the compatibility with Jetpack Related Posts, Duplicate Post, and worked around a bug in Nextgen Gallery preventing both plugins to work together.

Other less visible improvements and bug fixes are described in the changelog. Developpers having a plugin or a theme interacting directly with the PLL_Model class instead of the Polylang API should read the post dedicated to internal changes.

Last but not least, twelve translations are now taking profit of the plugins languages packs (automatically updated by the built in functionnality of WordPress): Albanian, Danish, Duch, French, Greek, Galician, Italian, Japanese, Portuguese, Romanian, Slovak and Swedish. Thanks a lot to the translators and translations editors!

The user profile is not saved for a language when the language code contains a “-“

It also fixes a conflict with the plugin Duplicate Post as translations were duplicated when they should not.

I also started removing po/mo files for translations being available as languages packs from the Translate WordPress project. This will allow automatic updates for these translations (once Polylang 1.8 will be released). At the time I write these lines, 9 languages packs are already available thanks to Polylang translations editors and global editors who did a fantastic job:

Like this:

As announced with the beta version, Polylang 1.8 will include several changes under the hood.

This version will introduce two new API functions, pll_get_post_translations() and pll_get_term_translations(), and a new WPML compatibility API function, wpml_get_language_information(). Note that all API are now available only once the action ‘plugins_loaded’ has been fired (they were available as soon as Polylang was loaded in previous versions).

When possible it is preferrable to use the API functions. This offers you the assurance that your plugin won’t break at Polylang update. However if for some reasons you need to interact with Polylang at low level, the function PLL() has been introduced to access the global Polylang object.

The most important for third party plugins interacting at low level with Polylang are the changes to the PLL_Model class. Posts and terms related methods have been moved to their own class. Here is an exhaustive list of methods removed from PLL_Model and examples of how to replace them:

Nothing should break as I introduced backward compatibility with the magic method __call(), however Polylang will trigger an error message when WP_DEBUG is set to true. There is no warranty that I will keep this magic method in the future.

Some other changes were done (for example, in the management of the static front pages) but I guess that these should have no impact for third party plugins. Anyway, it’s still better to use the beta period to test your theme(s) or plugin(s) against this new version.

For those, interacting directly at database level, no change was made in the way Polylang manages its data.

Share this:

Like this:

I am glad to announce the availability of the beta version of Polylang 1.8.

The most visible changes are in the settings of Polylang. Indeed it is now possible to select the flag for each language directly from the admin interface. Almost 250 flags are available. They are used on both admin and frontend side. However, it is still possible to use your own custom flags on frontend by putting them in the wp-content/polylang folder as before.

I totally revamped the settings tab. Choosing the default language or assigning this default language to the existing content is now done directly in the languages tab. Other options are now grouped by modules in a list table. This new interface mixes concepts from the plugins list table and the posts quick edit.

Advanced media users should be happy as I improved the compatibility with third party plugins using media taxonomies and custom fields. Indeed it is now possible to synchronize media taxonomies and custom fields as it was already the case for posts.

A lot of changes occured under the hood. These changes could impact how third party plugins interact with Polylang. I will detail them in a separate post dedicated to developpers.

Polylang 1.8 includes a few other minor changes and fixes a lot of bugs detailed in the changelog.

There are a lot of new strings (most of them being country names). As explained a few days ago, translations of Polylang are now managed on Translating WordPress. A positive effect is that a lot of the new strings have already been automatically translated and validated for major languages (probably taken from other projects). It’s very easy to help translating in your own language.

My plan is to release the final version in January. Don’t hesitate to download Polylang 1.8 beta, test it and report bugs in the support forum. Thanks!

Share this:

Like this:

I spent the past few weeks to test Polylang with the beta versions of WordPress 4.4. As a consequence of a change in taxonomies, Polylang 1.7.11 and older versions will not work with this future version of WordPress. Polylang 1.7.12 aims to fix this situation as well as a few other conflicts.

This release is also an opportunity to add the near complete translation in Moroccan Arabic, coming from the Translating WordPress project and update translations which have been significantly improved by this project (French, Indonesian and Portuguese). I did not included the translation in Albanian but it will be automatically downloaded as language pack.

Share this:

Like this:

Polylang is not available in your language? You noticed a typo or an incomplete translation? You can help!

For about two months, Polylang is available on Translating WordPress. Everybody with a wordpress.org account can translate the plugin. If you don’t have an account, registering won’t take you more than one minute.

One, two or more strings. It’s very easy. If sometimes you encounter strange codes such as %s, %1$s, just keep them as they are in the original string.

Once a translation editor has validated your translation, it will become available to the community for download. Once a translation reaches 100%, it is automatically downloaded and updated to all Polylang users using this language, just as it is the case for WordPress core since the version 4.0.

Translations are generally validated by global WordPress editors. But with WordPress, 2000 plugins already available for translation and even more themes, that’s a lot of work! It is thus possible to be a translation editor for only one plugin. Polylang has already 13 translation editors: