Category Archives: Development

Polylang 1.8 beta 2

I just uploaded a new development version of Polylang (1.8 beta 2). It fixes a few bugs, two of them being reported on the support forum:

  • Non alphanumeric characters query vars values lead to an infinite redirection loop on the static front page
  • 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:

  • Albanian thanks to Besnik, global editor
  • Italian thanks to Luca Barbetti, Polylang translation editor
  • Japanese thanks to Eiko Toda, Polylang translation editor
  • French thanks to fxbenard, global editor
  • Galician thanks to the global editor
  • Portuguese, thanks to the global editor
  • Romanian thanks to Philippe C. Focsaneanu, Polylang translation editor
  • Slovak thanks to Maros Kucera, Polylang translation editor
  • Swedish thanks to Jon Täng, Polylang translation editor

Contributing a translation is very easy. Please visit the Translate WordPress website. If you want to join the team of translation editors for Polylang, just leave a comment below.

Advertisements

Polylang 1.8 for the developpers

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:

get_object_term

Apply the same method to PLL_Model::$post or PLL_Model::$term:

Old:	$polylang->model->get_object_term( $object_id, $taxonomy )
New:	PLL()->model->post->get_object_term( $object_id, $taxonomy )
	PLL()->model->term->get_object_term( $object_id, $taxonomy )

save_translations
delete_translation
get_translations
get_translation
join_clause
where_clause
get_objects_in_language

Apply the same method to PLL_Model::$post or PLL_Model::$term and remove the ‘post’ or ‘term’  argument:

Old:	$polylang->model->save_translations( ‘post’, $id, $translations )
	$polylang->model->save_translations( ‘term’, $id, $translations )
New:	PLL()->model->post->save_translations( $id, $translations )
	PLL()->model->term->save_translations( $id, $translations )

set_post_language
get_post_language
get_post

Remove ‘_post’ from the method name and apply it to PLL_Model::$post

Old:	$polylang->model->set_post_language($post_id, $lang )
New:	PLL()->model->post->set_language($post_id, $lang )

set_term_language
get_term_language
delete_term_language
get_term

Remove ‘_term’ from the method name and apply it to PLL_Model::$term

Old:	$polylang->model->set_term_language($term_id, $lang )
New:	PLL()->model->term->set_language($term_id, $lang )

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.

Polylang 1.8 beta

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.

I attempted to work around an old bug in NextGen Gallery which prevents both plugins to work together. Although, a user proposed a fix, Nextgen Gallery has not been updated yet and I decided to include a workaround proposed by the Photocrati team. You might consider that it was a long time to wait, but this change is a bit risky and that’s the reason why I needed to wait for a major version. Hopefully Nextgen Gallery will fix its own bug in the future, as it’s always better to solve a problem at the source.

I also introduced a workaround for some WordPress locales which are not valid according to the W3C. Polylang will now automatically output the correct locale in the html source instead of the wrong one, normally outputed by WordPress.

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!

Translating Polylang

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:

Without forgetting global editors:

for those I am aware of. Thanks to them!

If you want to become a translation editor, just leave a comment (precising your wordpress.org username).

Polylang 1.7 beta2

Polylang is affected by the taxonomy term splitting which will be introduced in WordPress 4.2. To be honest, the code to adapt Polylang is ready for a while as the functionality was first planned for WordPress 4.1. However, it was not active. Now that it is re-introduced in the development version of WordPress 4.2, I activated it in this second beta version of Polylang 1.7.

I also fixed several bugs. You can download Polylang 1.7 beta2, test it and report bugs or regressions on the support forum.

Polylang 1.7 beta

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.

Polylang 1.5.6 and Polylang 1.6 beta2

Polylang 1.5.6 is a stability release which fixes a few bugs. It should also fix a conflict with the Avada theme which leaded to an ugly fatal error.

Download Polylang 1.5.6

I also updated the beta version of Polylang 1.6 to include these fixes and a few others related to this development version only.

Download Polylang 1.6 beta2