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.
Here comes a new maintenance release of Polylang and first of all, I would like to thank Cédric Valmary for a brand new translation in Occitan.
Several bugs or conflicts (with Lingotek translation, Jetpack infinite scroll, Yoast SEO and the theme Ambition) were fixed. But the most important change concerns navigation menus. For a while, Polylang conflicts with themes which incorrectly use wp_nav_menu. Hopefully I have found a workaround to detect these themes and fix the issue for most of them.
WordPress 4.3 also introduces several new languages packs. The corresponding languages are thus introduced in the predefined languages list.
Polylang 1.7.9 is a maintenance release focusing on the compatibility with WordPress 4.3 which is planned to be released tomorrow.
Indeed, WordPress 4.3 will introduce several conflicts with earlier versions of Polylang. This mainly concerns the menus and the customizer. This new version aims at fixing these conflicts.
However, the language switcher is not yet compatible with the new customizer menus. There is still some work to be done in WordPress to allow plugins to have menu items with custom forms (as done by Polylang for the language switcher). Of course, you can still add a language switcher menu item in Appearance->Menus as usual.
Under the hood, WordPress 4.3 will eliminate all shared taxonomy terms. Not all users have shared terms in the database but for those who have, this impacts Polylang. The compatibility code is there since Polylang 1.7 and the core team helped a lot to make things happen as smoothly as possible, but making a database backup before upgrading to WordPress 4.3 is well recommended.
Finally this version fixes also a conflict with Yoast SEO sitemaps (when using multiple domains) and improves the usage of hreflang in the alternate links added by Polylang in the html head.
Polylang 1.6.5 fixes a couple of bugs discovered in the past two weeks but the main goal is to fix a conflict introduced by the release or WordPress SEO 1.7.2 & 1.7.3 yesterday and which impacted users who are setting the language by the content.
For most users, WordPress SEO and Polylang should work correctly together, provided that you use pretty permalinks and don’t set the language from the content (yes, although I like this feature, I must agree that it does not play nice with all plugins).
For what is related to sitemaps, the basic idea of the WPSEO compatibilty code included in Polylang is to mix all languages in the same sitemap. This works great when setting the language from the directory name in url. This is also what is generally done in other compatible sitemap plugins such as XML sitemap and Google News feeds. I like this approach as it eases the task of the website admin.
This should have worked whatever option you choose to set the language (directory name, subdomain or multiple domains), but Joost de Valk and I don’t share the same view and WordPress SEO explicitely removes from the sitemap all the content from subdomains and domains which are not the one defined in your WordPress general settings, thus keeping only the content from the default language 😦
I had thus to work around this and Polylang 1.6.4 introduces a separate sitemap per subdomain or domain when using WordPress SEO (while keeping the unique sitemap in other cases). If you have subdomains and prefer to have only one sitemap, XML sitemap and Google News feeds seems to be currently a better choice.
Polylang 1.6.4 fixes a few other bugs reported by users during the past month.
Although maybe not the most visible new feature, WordPress 4.0 introduced a new way to manage WordPress translations files. Polylang 1.6 takes profit of this new feature and makes it compatible with multilingual websites, thus allowing managing WordPress translations in a much clever way than it was with previous versions. This works also for default Twenty themes and a few plugins (Akismet, WordPress Importer, BuddyPress…), managed by the WordPress translation project. All these translations can now be updated from the updates panel in the WordPress dashboard.
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), and the support of opengraph language and translations metadata for websites running Jetpack or WordPress SEO.
To avoid a common mistake, Polylang will now force users to choose a static front page translated in all languages.
Some US users complained about my choice to associate the British flag to English (en_US). With the introduction of a new WordPress English (en_GB) language pack, I decided to change this. This means that from now, the British flag is associated to en_GB and the US flag is associated to en_US. Old users who kept the default flag for en_US will thus see the flag associated to the English language change when updating to Polylang 1.6. There are 2 different ways to come back to the British flag:
1. Edit the English language and change the locale from en_US to en_GB. This will also impact the html ‘lang’ markup and the WordPress en_GB translation will be used.
2. Create a polylang directory in wp-content. Copy the British flag wp-content/plugins/polylang/flags/en_GB.png to wp-content/polylang/en_US.png. This will impact only the flag on frontend, not on backend side.
Another important change concerns the Belarussian language, for which the default locale was changed from be_BY to bel to follow the WordPress locale.
Finally, I would like to thank all translators who updated Polylang translations with special thanks to Bajro who provided a brand new Croatian translation.
I am glad to announce the availability of Polylang 1.5.4. I continue to improve the API for a better interaction with themes and third party plugins and this release comes with 3 new functions: pll_get_post_language, pll_get_term_language and pll_translate_string.
The compatibility with Jetpack 3 has been improved by adapting the WPML specific code included in jetpack to Polylang. A conflict with WordPress SEO has been solved.
A few users have been annoyed with too restrictive permissions. This should now be fixed. And a couple of other bugs have been fixed too.