Filter reference

Filter reference

pll_copy_post_metas
Allows plugins to copy custom fields when a new post (or page) translation is created or synchronizing them. Filter arguments:

$metas => an array of post metas
$sync => false when copying custom fields to a new translation, true when synchronizing translations
$from => Id of the post from which we copy informations
$to => Id of the post to which we paste informations
$lang => Language slug

Example:
12345add_filter( ‘pll_copy_post_metas’, ‘copy_post_metas’ ); function copy_post_metas( $metas ) {    return array_merge( $metas, array( ‘my_post_meta’ ) );}
pll_translate_post_meta
Allows plugins to modify custom fields when it is copied from one post to a translation. This is typically used in combination with `pll_copy_post_metas’ to translate the custom field. Filter arguments:

$value => Meta value
$key => Meta key
$lang => Language slug of the target post
$from => Id of the post from which we copy informations
$to => Id of the post to which we paste informations

Example:
12345678add_filter( ‘pll_translate_post_meta’, ‘translate_post_meta’, 10, 3 ); function translate_post_meta( $value, $key, $lang ) {    if ( ‘_thumbnail_id’ === $key ) {            $value = pll_get_post( $value, $lang );    }    return $value;}
pll_copy_term_metas
Allows plugins to copy term metas when a new term translation is created or synchronizing them. The usage is similar to the filter ‘pll_copy_post_metas’.
pll_translate_term_meta
Allows plugins to modify term metas when it is copied from one term to a translation. This is typically used to translate the term meta. The usage is similar to the filter ‘pll_translate_post_meta’.
pll_copy_taxonomies
Allows plugins to copy taxonomy terms when a new post (or page) translation is created or synchronize them. Filter arguments:

$taxonomies => list of taxonomy names
$sync => true if it is synchronization, false if it is a copy
$from => Id of the post from which we copy informations
$to => Id of the post to which we paste informations
$lang => Language slug

Example:
123456add_filter( ‘pll_copy_taxonomies’, ‘copy_tax’, 10, 2 ); function copy_tax( $taxonomies, $sync ) {    $taxonomies[] = ‘my_custom_tax’;    return $taxonomies;}
pll_translation_url
Allows plugins to modify (or create) the translation url. This is thus a more generic filter than ‘pll_the_languages_link’ described below. Filter arguments:

$url => the translation URL to modify (set to null if there is no translation available)
$slug => the 2-letters language iso-code of the translation

pll_the_language_link
Allows plugins to modify the translation link outputed by the language switcher (valid for the widget, the nav menus and the function pll_the_languages). Filter arguments:

$url => the translation URL to modify (set to null if there is no translation available)
$slug => the 2-letters language iso-code of the translation
$locale => the WordPress locale for the language of the translation

Example (to link to the posts list in the right language when there is no translation available):
12345add_filter( ‘pll_the_language_link’, ‘my_link’, 10, 2 ); function my_link( $url, $slug ) {    return $url === null ? home_url( ‘?lang=’ . $slug ) : $url;}
pll_flag_title
Allows plugins to modify the title attribute of the flag in the language switcher (defaults to language name). Filter arguments:

$title => the title attribute
$slug => the 2-letters language iso-code of the translation
$locale => the WordPress locale for the language of the translation

Example:
123456789101112131415add_filter( ‘pll_flag_title’, ‘my_flag_title’, 10, 2 ); function my_flag_title( $title, $slug ) {    switch( $slug ) {        case ‘en’:            return ‘The blog in ‘ . $title;        break;        case ‘fr’:            return ‘Le blog en ‘ . $title;        break;        default:            return $title;        break;    }}
pll_the_languages
Allows plugins to modify the whole output of the language switcher. Filter arguments:

$output => the output of the language filter
$args => the arguments of the function pll_the_languages

Example (to add a link to the flag file in the title attribute of the dropdown list which maybe useful used together with a script adding a picture in the dropdown):
12345678910111213add_filter( ‘pll_the_languages’, ‘my_dropdown’, 10, 2 ); function my_dropdown( $output, $args ) {    if ( ! $args[‘dropdown’] ) {        return $output;    }    foreach ( array( ‘en_US’, ‘fr_FR’, ‘de_DE’ ) as $lang ) {        $file = POLYLANG_DIR . ”/flags/$lang.png”;        $value = reset( explode( ‘_’, get_locale() ) );        $output = str_replace( “value=’$value’”, “value=’$lang’ title=’$file’”, $output );    }    return $output;}
pll_the_languages_args
Allows plugins to filter the arguments passed to the function pll_the_languages used to display a language switcher. Filter arguments:

$args => the arguments of the function pll_the_languages

Example (to display the language code instead of the language native name in the language switcher):
123456add_filter( ‘pll_the_languages_args’, ‘my_language_switcher_args’ ); function my_language_switcher_args( $args ) {    $args[‘display_names_as’] = ‘slug’;    return $args;}
pll_get_post_types
Allows plugins to modify the list of post types which will be filtered by language. The default are custom post types which have the parameter ‘public’ set to true. The filter must be added soon in the WordPress loading process: in a function hooked to ‘plugins_loaded’ or directly in functions.php for themes. Filter arguments:

$post_types => the array of post type names
$is_settings => true when displaying the list of custom post types in Polylang settings (avoid the user to modify the decision made by the plugin author for a post type)

Example:
123456789101112add_filter( ‘pll_get_post_types’, ‘add_cpt_to_pll’, 10, 2 ); function add_cpt_to_pll( $post_types, $is_settings ) {    if ( $is_settings ) {        // hides ‘my_cpt’ from the list of custom post types in Polylang settings        unset( $post_types[‘my_cpt’] );    } else {        // enables language and translation management for ‘my_cpt’        $post_types[‘my_cpt’] = ‘my_cpt’;    }    return $post_types;}
pll_get_taxonomies
Allows plugins to modify the list of taxonomies which will be filtered by language. The default are taxonomies which have the parameter ‘public’ set to true (which include categories and post tags). The filter must be added soon in the WordPress loading process: in a function hooked to ‘plugins_loaded’ or directly in functions.php for themes. Filter arguments:

$taxonomies => the array of taxonomy names
$is_settings => true when displaying the list of custom taxonomies in Polylang settings (avoid the user to modify the decision made by the plugin author for a taxonomy)

Example:
12345678910add_filter( ‘pll_get_taxonomies’, ‘add_tax_to_pll’, 10, 2 ); function add_tax_to_pll( $taxonomies, $is_settings ) {    if ( $is_settings ) {        unset( $taxonomies[‘my_tax’] );    } else {        $taxonomies[‘my_tax’] = ‘my_tax’;    }    return $taxonomies;}
pll_rewrite_rules
Allows plugins to inform Polylang of a new rewrite rules filter to use (allowing this rules to be filtered by language. Filter arguments:

$rules => the array rewrite rules to filter

Example:
123456789101112// create rewrite rules with a filter ‘something_rewrite_rules’add_filter( ‘generate_rewrite_rules’, ‘my_rules’ ); function my_rules( $wp_rewrite ) {    $rules[] = …    $rules = apply_filters( ‘my_own_rewrite_rules’, $rules );    $wp_rewrite->rules = array_merge( $rules, $wp_rewrite->rules );}// add the filter (without ‘_rewrite_rules’) to the Polylang listadd_filter( ‘pll_rewrite_rules’, function( $rules ) {    return array_merge( $rules, array( “my_own” ) ); } );
pll_preferred_language
Allows plugins to modify the visitor preferred language (normally set first by cookie if this is not the first visit, then by the browser preferences). If no preferred language has been found or set by this filter, Polylang fallbacks to the default language. Filter arguments:

$slug => language code or false if no preferred language has been found

Example:
123456// fallback language is English whatever the default languageadd_filter( ‘pll_preferred_language’, ‘my_language_fallback’ ); function my_language_fallback( $slug ) {    return $slug === false ? ‘en’ : $slug;}
pll_get_flag
Allows plugins to modify the html output of flags (the images). Filter arguments:

$flag => html output of one flag
$slug => language code

Example:
123456// displays language code instead of flags on admin sideadd_filter( ‘pll_get_flag’, ‘no_flag_on_admin’ ); function no_flag_on_admin( $flag ) {    return is_admin() ? ” : $flag;}
pll_redirect_home
When a visitor reaches the home, Polylang redirects to the home in the correct language. This filter allows plugins to modify the redirected url or prevent this redirection. Filter arguments:

$redirect => the redirected url. If set to false, there will be no redirection.

Example:
12// prevents home redirectionadd_filter( ‘pll_redirect_home’, ‘__return_false’ );
Note: You must add this filter in a custom plugin as it is generally applied before the theme is loaded.
pll_sanitize_string_translation
Allows to sanitize strings registered with pll_register_string. Filter arguments:

$string => the translated string to sanitize
$name => string name
$group => the group in which the string is registered

pll_cookie_expiration
Allows to modify the cookie duration. Filter arguments:

$duration => the cookie duration in seconds. Defaults to one year

Note: You must add this filter in a custom plugin as it is generally applied before the theme is loaded.
pll_rel_hreflang_attributes
Allows to modify hreflang attributes displayed in the html head on frontend. Filter arguments:

$hreflangs => Array of urls with language codes as keys and links as values

pll_custom_flag
Allows to modify a flag url and size. Filter arguments:

$flag => An array of information with ‘url’,’src’, height’, ‘width’ keys. The url is mandatory. The 3 other parameters are optional. The ‘height’ and ‘width’ parameters are especially useful for SVG flags.
$code => Flag code

Notes:

The filter needs to be added in a plugin or mu-plugin before the action ‘plugins_loaded’ has been fired. It can’t work in the functions.php of a theme.
The filter acts only on flags displayed on frontend. The flags used in the backend are kept unchanged.
After you have changed the code in the filter, go to Languages > Settings. Click on the “URL modifications” settings and then on Save Changes, to reset the transient storing the languages.

Example:
12345678add_filter( ‘pll_custom_flag’, ‘pll_custom_flag’, 10, 2 ); function pll_custom_flag( $flag, $code ) {    $flag[‘url’]    = “http://mysite.com/wordpress/wp-content/polylang/{$code}.svg”;    $flag[‘width’]  = 32;    $flag[‘height’] = 22;    return $flag;}
pll_flag
This filter works the same as ‘pll_custom_flag’ except that it acts both on frontend and backend.
pll_pre_current_user_can_synchronize_post
Used to decide if a synchronizations capability check should take place when a user doesn’t have the right to edit one of the translated posts. Filter arguments:

$check => null to enable the capability check, true to allow the synchronization, false to disallow the synchronization. Defaults to true.
$post_id => Id of the synchronization source post.

Example:
1add_filter( ‘pll_pre_current_user_can_synchronize_post’, ‘__return_null’ );

WPML API

WPML API

The WordPress multilingual plugin WPML has been created far before Polylang and thus some plugins and themes have been written to play nicely with it. Polylang does support most of the WPML API to avoid double work for themes and plugins author. WPML 3.2 introduced a new API based on filters and actions rather than functions. It is not supported yet.
The constants ICL_LANGUAGE_CODE and ICL_LANGUAGE_NAME are supported.
icl_get_home_url
Polylang equivalent: pll_home_url
Link to the home page in the active language.
Usage:
1icl_get_home_url();
icl_get_languages
Polylang equivalent: none
Used for building custom language selectors
Usage:
1icl_get_languages($args);
$args is an optional array parameter. Options are:

‘orderby’ => ‘slug’, ‘name’ or ‘id’ (default: ‘id’)
‘order’ => ‘DESC’ or ‘ASC’ (default: ‘ASC’)
‘skip_missing’ => 0 or 1 (default: 0)
link_empty_to => works in conjunction with skip_missing=0 and allows using custom links for the languages that do not have translations for the current element. {$lang} can be used as placeholder for the language code (default: empty)

icl_link_to_element
Polylang equivalent: none
used for creating language dependent links
Usage:
1icl_link_to_element($id, $type, $text, $args, $anchor);

$id => (required) the ID of the post, page, tag or category to link to
$type => (optional) the type of page to link to. Can be ‘post’, ‘page’, ‘tag’ or ‘category’. (default: ‘post’)
$text => (optional) the link text. If not specified, the name of the element will be used.
$args => (optional) arguments for the link. When used, this should be a PHP array
$anchor => (optional) anchor for the link

icl_object_id
Polylang equivalent: pll_get_post and pll_get_term
returns the tranlation id of an object
Usage:
1icl_object_id($id, $type, $return_original_if_missing, $lang);

$id => (required) the ID of the post, page, tag or category
$type => (required) ‘post’, ‘page’, post_tag’ or ‘category’.
$return_original_if_missing => (required) true if Polylang should return the ID of the original language element if the translation is missing or false if Polylang should return a NULL if translation is missing
$lang => (optional) if set, forces the language of the returned object and can be different than the displayed language

icl_register_string
Polylang equivalent: pll_register_string
Allows plugins to add their own strings in the “strings translation” panel. Unlike pll_register_string, icl_register_string stores the string in the database (as the WPML original function does).
Usage:
1icl_register_string($context, $name, $string);

$context => (required) the name of the plugin
$name => (required) the name of the string
$string => (required) the string that needs to be translated

icl_unregister_string
Polylang equivalent: none
Removes a string from the database
Usage:
1icl_unregister_string($context, $name);

$context => (required) the name of the plugin
$name => (required) the name of the string

icl_t
Polylang equivalent: pll__
get the translated string
Usage:
1icl_t($context, $name, $string);

$context => (required) the name of the plugin
$name => (required) the name of the string
$string => (optional) the string that needs to be translated

The wpml-config.xml file

The wpml-config.xml file

The WordPress multilingual plugin WPML has been created far before Polylang and thus some plugins and themes have been written to play nicely with it. Polylang does support the WPML language configuration file wpml-config.xml to avoid double work for themes and plugins author.
Here is an example which is pretty much self explanatory:
123456789101112131415161718192021222324            quantity        custom-title                book        DVD                genre                                                                                                                    
custom-fields: the custom field name needs to be provided and also the action that Polylang is expected to take:

“ignore”: no action from Polylang
“translate”: the custom field is copied from the source post but may be modified
“copy”: the custom field is copied from the source post and synchronized accross translations

custom-types: the custom post types that Polylang should manage. Allowed values for the “translate” attribute are 1 (managed by Polylang) and 0 (not managed by Polylang). In both cases, users cannot change this choice in Polylang settings.
taxonomies: the custom taxonomies that Polylang should manage. Allowed values for the “translate” attribute are 1 (managed by Polylang) and 0 (not managed by Polylang). In both cases, users cannot change this choice in Polylang settings.
admin-texts: When themes and plugins use ‘get_option’, Polylang can filter these calls and provide translation to the values of these options. To translate a single option, add a key entry under admin-texts (as simple_string_option in the example above). To translate a serialized array, add several keys under a key (as in my_plugin_options in the example above).
Polylang does not support the section.
Developpers must place the wpml-config.xml file in the root directory of the plugin or theme. It is also possible for users to create their own wpml-config.xml file and to upload it in /wp-content/polylang/ (create the directory if it does not exist).

How to translate options with a wpml-config.xml file?

How to translate options with a wpml-config.xml file?

Adding a simple option in the wpml-config.xml
Writing the wpml-config.xml file
Adding a serialized option in the wpml-config.xml
My wpml-config.xml is written, what should I do now ?
I already have a wpml-config.xml, may I merge two in one ?

Introduction
The wpml-config.xml file is a powerful tool which allows to add WordPress themes and plugins options to the string translations.
This tutorial explains how to find the information to add in this file to translate option strings easily.
Prerequisite
To follow this tutorial you’ll need a PhpMyAdmin access to find how options are stored and named. We suggest you to test it in a development environment before using it on your production website.
If you are not sure about your ability to manage this tutorial, do not hesitate to contact us in our Polylang Pro help desk.
Warning
In this tutorial, we’ll access to PhpMyAdmin which is a tool to manage databases. A wrong manipulation of data may break your website.
Always make a database backup before manipulating it.
Adding a simple option in the wpml-config.xml
To illustrate we’ll use the plugin WooCommerce. Thanks to Polylang for WooCommerce you’ll be able to send emails to your customer in the language they purchased.
That said, you may want to translate the email sender options in each language that you have in your website:

Now our goal is to find how WooCommerce stores these options and which names it uses.

Fill each fields and save the options, to store them in the database.
Open PhpMyAdmin and go to the wp_options table
click on “Search” tab

Fill the search fields with:

“Option value” selected on “LIKE %…%”. The % sign will allows to hav characters before and after the searched string.
Paste the value on the searched option: “Polylang Helpdesk” in our case.

Click on “Execute”
You should have something like:

The info needed here is “woocommerce_email_from_name”. Copy the data (Do not cut).

Writing the wpml-config.xml file
In your preferred text editor, add the code below in a new file called wpml-config.xml:

must be the first tag in your wpml-config.xml file, and must be the last one. Polylang will only process instructions between these tags.
… will contain the options we want to translate.
Adds a simple option (not serialized) to our string translation. The name ‘woocommerce_email_from_name’ is the option name found earlier in PhpMyAdmin.

Of course, you can have several inside your admin-texts section.
Adding a serialized option in the wpml-config.xml
Some themes or plugins are storing an array of options in the same option key in the database. WordPress serializes the data to store them correctly.
To illustrate this chapter, we’ll use the plugin WPFront Notification Bar. This plugin allows to spread a message in a bar in your front-end website. In the settings of this plugin, you’ll find several textareas and input fields for text.

Here the goal is to translate “My great text”, “toto”,  “https://polylang.pro”.
As in the previous chapter, we’ll search one of the string in the databases:

At this point, we can start to write (or edit an existing) wpml-config.xml:

Here the important information is the syntax that is used for serialized options. Now, let’s unserialize “option_value”.

Copy the “option_value” content
Paste it in the field present on this URL https://www.unserialize.com/
click on “Unserialize”

Here a screenshot of what you should have :

The information we need here are the option key:

message
button_text
button_action_url

Which are sub-keys of our main option_name “wpfront-notification-bar-options”. Our wpml-config.xml should be modified as follow:

My wpml-config.xml is written, what should I do now ?
Simply upload it to your FTP in
wp-content/polylang
(you may need to create this folder)
Go to Polylang’s Strings Translations page and save your plugins settings again. You should now have a new group called “Polylang” in your strings translations with your new strings.

I already have a wpml-config.xml, may I merge two in one ?
Of course, be sure to copy the content inside the

tags
Let’s say you already have:

et_pb_layout

and need to add the previous instructions, you can merge both wpml-config.xml like below:

et_pb_layout

PHP Constants

PHP Constants

It is possible to change the default way Polylang works by setting some options in wp-config.php. You can add a line such as:
1define(‘OPTION’, false);
above the comment:
/* That’s all, stop editing! Happy publishing. */
Alternatively, it is possible to create a file named ‘pll-config.php’ in the directory ‘/wp-content/polylang/’ (you have to create the directory too) and set the options in this file instead of ‘wp-config.php.’
PLL_FILTER_HOME_URL
Defaults to true.
This option allows Polylang to return the url of the homepage in the right language instead of the default homepage. Although the feature allows Polylang working with a lot of themes without any modification, it may break some themes. If you set it to false, you will need to modify your theme and replace calls to home_url(), home_url(‘/’), bloginfo(‘url’), get_bloginfo(‘url’) by pll_home_url() if you want a link to the homepage in the right language.
PLL_SEARCH_FORM_JS
Defaults to true.
Prior to WordPress 3.6, adds javascript code to modify the search form when using default permalinks.
PLL_MEDIA_SUPPORT (deprecated)
Removed in v1.0 as it is now useless. Use the corresponding option in Polylang settings instead.
PLL_COOKIE
Defaults to ‘pll_language’.
Defines the name of the cookie used by Polylang to store the visitor’s language.
When PLL_COOKIE is set to false, Polylang does not set any cookie. Be aware that in this case, not everything will work correctly. For example, the login page will not translate.
PLL_WPML_COMPAT
Defaults to true.
Wether to load the WPML API.
PLL_PLUGINS_COMPAT
Defaults to true.
Wether to load support of some 3rd party plugins. Currently concerns WordPress SEO by Yoast, YARPP, Custom field template, Jetpack (infinite scroll)
PLL_WIDGET_CALENDAR
Defaults to true.
Wether to load the calendar widget modified by Polylang.
PLL_AUTO_TRANSLATE
Defaults to true.
Some themes query a specific category for a specific usage (such as a slider). By default Polylang automatically queries the translation of this specific category when it exists. The option allows to enable / disable the feature.
PLL_CACHE_HOME_URL
Defaults to true.
By default, Polylang caches the urls of homepages in all languages. This is not compatible with websites accessible from more than one domain (as only one domain is cached). The option allows to disable the cache and thus make Polylang compatible with multiple domains.
PLL_ENCODED_FLAGS
Defaults to true.
By default, Polylang encodes the flags (only those provided with the plugin) directly in the html request instead of linking to image files. This is nice for performances as it avoids one http request per flag, but is no compatible with Internet Explorer 6 & 7. The option allows to disable the flags encoding for websites needing to be compatible with these old browsers.

REST API

REST API

The feature is available only in Polylang Pro.
The ‘lang’ argument
It is possible to get posts or terms in only one language. For example:
1GET /wp/v2/posts?lang=fr
lists all posts in French, while
1GET /wp/v2/posts
lists all posts in all languages.
The ‘lang’ argument works for requests related to the posts and terms, whatever the post type or taxonomy.
The language and translations in responses
When querying posts or terms, two new fields are added to the response.

‘lang’: contains the language code (generally 2 letter ISO code) of the queried post or term.
‘translations’: contains an array with the language codes as keys and the id of the translated posts or terms as values. The array always includes the queried post or term itself.

Assign the language and translations
It is not only possible to get the language and translations of posts and terms but it is also possible to assign them. For example:
1POST /wp/v2/posts/3376?lang=fr&translations[en]=3374
will assign the French language to the post 3376 and link it to the post 3374 as its English translation. Note that you must first make sure that the post 3374 is in English.
Get the languages
Apart from extending the WP API, it is possible to get the languages with an additional endpoint:
1GET /pll/v1/languages
The response will include several properties such as:

name: native language name
slug: language code (generally 2 letter ISO code)
locale: WordPress locale
flag_url: the url of the flag associated to the language
home_url: the url of the home page in that language
page_on_front: if relevant, the id of the static front page in that language
page_for_posts: if relevant, the id of the page for posts in that language

The list above is not exhaustive as the response includes several other internal properties.

Is it possible to use a static front page?

Is it possible to use a static front page?

Yes. You have to create one page per language. Set translations as usual and then go to the WordPress ‘Reading settings’ panel. Check ‘Front page displays a static page’ and choose one of the page you have just created. The language doesn’t matter. You can do the same for the posts page.
Then, if you want that the url looks like http://www.yoursite.com/en/ instead of http://www.yoursite.com/startpage/, go to Settings > Languages > Settings and check the option “The front page url contains the language code instead of the page name or page id” in the URL modifications section.

Is Polylang compatible with multisite?

Is Polylang compatible with multisite?

Yes it is. Polylang is fully tested in a multisite environment, activated at site level.
It should also work when network activated but is not so well tested in this configuration. In most cases, it shouldn’t be useful to network activate Polylang.

Can posts or terms share the same URL slug across translations?

Can posts or terms share the same URL slug across translations?

With Polylang Pro comes the possibility to share slugs between posts and pages.
By default WordPress will not allow two pages or posts to share the same slug. That is to say if two posts are created with the same slug, WP will automatically add a “-2” to the slug of the second post created, “-3” to the third etc.
URLs contribute to the first impression visitors will have of your site. Long URLs that contain random numbers and/or letters appear less trustworthy than URLs that convey accurate information related to the content of the page. This is where sharing slugs can come in handy.

This feature allows you to share the same slug between translations for all types of content, pages, posts, categories, tags, media, custom taxonomies… You need to use pretty permalinks and the language must not be set from the content for it to be activated.
For posts, pages, custom post types
Taken an author is presented in a post (Agatha Christie), it is useful to share the same slug between languages as the post name showing in the URL should be the same regardless of the language. If you have two languages (English and French), with Polylang Pro you will get this result:

For categories, tags, custom taxonomies
If a site references books, movies and authors. While the title of the books and the movies may vary between languages, authors’ names are unlikely to change. Taken each author corresponds to a category, it becomes possible with Polylang Pro to keep the same slug for each translation of the category
So with Polylang Pro you will get this result:

/en/category/agatha-christie
/fr/category/agatha-christie

Instead of having with Polylang:

/en/category/agatha-christie
/fr/category/agatha-christie-fr

Note that it is also possible to translate the category base in the Languages => Strings Translations tab. See translating URLs slugs.
 
Note: It’s a known issue that when using the WordPress Importer plugin, the content having a shared slug is not imported.
Note: If you deactivate Polylang Pro, only one item among all sharing the same slug will be displayed.

Is Polylang compatible with the EU cookie law?

Is Polylang compatible with the EU cookie law?

Polylang uses a cookie to remember the language selected by the user when he comes back to visit again the website. This cookie is also used to get the language information when not available in another way. Examples are ajax requests or the login page.
According to the section 3.6 of the  Opinion 04/2012 on Cookie Consent Exemption, this cookie is part of the user interface customization and may be considered as requested by the user. Whether it requires the explicit consent of the user seems to depend on the expiration time or the information provided on your website. Moreover European countries have all their own law and do not apply the European directive the same way. Please check if this cookie requires an explicit user consent in your own country.
Here are the information about the cookie used by Polylang:

Default name: ‘pll_language’, can be changed by setting the constant PLL_COOKIE
Value: the language code of the last browsed page
Default expiration time: 1 year, can be changed with the filter ‘pll_cookie_expiration’

It is possible not to use the cookie (be aware however that in this case and as stated above, not everything will work correctly)  by putting the code below for example in your wp-config.php file:
1define( ‘PLL_COOKIE’, false);