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.
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
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).
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
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' );
Function reference
IMPORTANT: when using one or more of these function, you *must* check for its existence before using it, otherwise your site will badly break with a fatal error at next Polylang update (as WordPress deletes the plugin when updating it).
pll_the_languages
Displays a language switcher.
Usage:
1pll_the_languages( $args );
$args is an optional array parameter. Options are:
『dropdown』 => displays a list if set to 0, a dropdown list if set to 1 (default: 0)
『show_names』 => displays language names if set to 1 (default: 1)
『display_names_as』 => either 『name』 or 『slug』 (default: 『name』)
『show_flags』 => displays flags if set to 1 (default: 0)
『hide_if_empty』 => hides languages with no posts (or pages) if set to 1 (default: 1)
『force_home』 => forces link to homepage if set to 1 (default: 0)
『echo』 => echoes if set to 1, returns a string if set to 0 (default: 1)
『hide_if_no_translation』 => hides the language if no translation exists if set to 1 (default: 0)
『hide_current』=> hides the current language if set to 1 (default: 0)
『post_id』 => if set, displays links to translations of the post (or page) defined by post_id (default: null)
『raw』 => use this to create your own custom language switcher (default:0)
Important: You have to output yourself the ul tags if you don』t use the dropdown option.
Examples:
123456789101112
- 1,'show_names' => 0 ) ); ?>
1 ) ); ?>
If the options are not enough, you can build your own custom language switcher using the 『raw』 argument:
1$translations = pll_the_languages( array( 'raw' => 1 ) );
The function will return an array of arrays, one array per language with the following entries:
[id] => language id
[slug] => language code used in urls
[name] => language name
[url] => url of the translation
[flag] => url of the flag
[current_lang] => true if this is the current language, false otherwise
[no_translation] => true if there is no available translation, false otherwise
The function is meant to display a language switcher. So it is not availaible on backend. If you need a function to get information about available languages, you should use pll_languages_list() instead.
pll_current_language
Returns the current language
Usage:
1pll_current_language( $value );
『$value』 => (optional) either 『name』 or 『locale』 or 『slug』, defaults to 『slug』
returns either the full name, or the WordPress locale (just as the WordPress core function 『get_locale』 or the slug ( 2-letters code) of the current language.
pll_default_language
Returns the default language
Usage:
1pll_default_language( $value );
『$value』 => (optional) either 『name』 or 『locale』 or 『slug』, defaults to 『slug』
returns either the full name, or the WordPress locale (just as the WordPress core function 『get_locale』 or the slug ( 2-letters code) of the current language.
pll_get_post
Returns the post (or page) translation
Usage:
1pll_get_post( $post_id, $slug );
『$post_id』 => (required) id of the post you want the translation
『$slug』 => (optional) 2-letters code of the language, defaults to current language
returns the id of the translated post or page as integer.
pll_get_term
Returns the category (or post tag) translation
Usage:
1pll_get_term( $term_id, $slug );
『$term_id』 => (required) id of the term you want the translation
『$slug』 => (optional) 2-letters code of the language, defaults to current language
returns the id of the translated term as integer.
pll_home_url
Returns the home page url
Usage:
1pll_home_url( $slug );
『$slug』 => 2-letters code of the language. The parameter is optional and defaults to the current language if the function is called on frontend.
returns the url of the homepage in the requested language, as a string.
pll_register_string
Allows plugins to add their own strings in the 「strings translation」 panel. The function must be called on admin side (the functions.php file is OK for themes). It is possible to register empty strings (for example when they come from options) but they won』t appear in the list table.
Usage:
1pll_register_string( $name, $string, $group, $multiline );
『$name』 => (required) name provided for sorting convenience (ex: 『myplugin』)
『$string』 => (required) the string to translate
『$group』 => (optional) the group in which the string is registered, defaults to 『polylang』
『$multiline』 => (optional) if set to true, the translation text field will be multiline, defaults to false
pll__
translates a string previously registered with pll_register_string
Usage:
1pll__( $string );
The unique parameter is required:
『$string』 => the string to translate
returns the translated string.
pll_e
Echoes a translated string previously registered with pll_register_string
Usage:
1pll_e( $string );
The unique parameter is required:
『$string』 => the string to translate
pll_translate_string
Translates a string previously registered with pll_register_string in a given language. Unlike 『pll__()』 and 『pll_e()』 which allow to get the translation only in the current language (as do the WordPress localization functions 『__()』 and 『_e()』), this function allows to get the translation in any language.
Usage:
1pll_translate_string( $string, $lang );
『$string』 => the string to translate
『$lang』 => the language code of the desired translation
returns the translated string.
pll_is_translated_post_type
Returns true if Polylang manages languages and translations for this post type, false otherwise
Usage:
1pll_is_translated_post_type( $post_type );
The unique parameter is required:
『$post_type』 => the post type to check
pll_is_translated_taxonomy
Returns true if Polylang manages languages and translations for this taxonomy, false otherwise
Usage:
1pll_is_translated_taxonomy( $tax );
The unique parameter is required:
『$tax』 => the taxonomy to check
pll_languages_list
Returns the list of languages
Usage:
1pll_languages_list( $args );
$args is an optional array parameter. Options are:
『hide_empty』 => hides languages with no posts if set to 1 (default: 0)
『fields』 => returns only that field if set. Possible values are 『slug』, 『locale』, 『name』, defaults to 『slug』
pll_get_post_language
gets the language of a post or page (or custom post type post)
Usage:
1pll_get_post_language( $post_id, $field );
『$post_id』 => (required) id of the post for which you want to get the language
『$field』 => (optional) either 『name』 or 『locale』 or 『slug』, defaults to 『slug』
returns either the full name, or the WordPress locale or the slug ( 2-letters code) of the post.
pll_get_term_language
gets the language of a category or post tag (or custom taxonomy term)
Usage:
1pll_get_term_language( $term_id, $field );
『$term_id』 => (required) id of the term for which you want to get the language
『$field』 => (optional) either 『name』 or 『locale』 or 『slug』, defaults to 『slug』
returns either the full name, or the WordPress locale or the slug ( 2-letters code) of the term.
pll_set_post_language
Sets the language of a post or page (or custom post type post)
Usage:
1pll_set_post_language($post_id, $lang);
『$post_id』 => (required) id of the post for which you want to set the language
『$lang』 => (required) language code
pll_set_term_language
Sets the language of a category or post tag (or custom taxonomy term)
Usage:
1pll_set_term_language( $term_id, $lang );
『$term_id』 => (required) id of the term for which you want to set the language
『$lang』 => (required) language code
pll_get_post_translations
Returns an associative array of translations with language code as key and translation post_id as value
Usage:
1pll_get_post_translations( $post_id );
『$post_id』 => (required) id of the post for which you want to get the translations
pll_get_term_translations
Returns an associative array of translations with language code as key and translation term_id as value
Usage:
1pll_get_term_translations( $term_id );
『$term_id』 => (required) id of the term for which you want to get the translations
pll_save_post_translations
Defines which posts are translations of each other
Usage:
1pll_save_post_translations( $arr );
『$arr』 => (required) associative array of translations with language code as key and post id as value
pll_save_term_translations
Defines which terms are translations of each other
Usage:
1pll_save_term_translations( $arr );
『$arr』 => (required) associative array of translations with language code as key and term id as value
pll_count_posts
Counts posts in a defined language
Usage:
1pll_count_posts( $lang, $args );
『$lang』 => (required) language code
『$args』 => (optional) allows to restrict the count to a certain class of post archive. Accepted keys are 『post_type』, 『m,』 『year』, 『monthnum』, 『day』, 『author』, 『author_name』, 『post_format』
How to translate emails?
Since the version 4.7, WordPress introduced the function switch_to_locale(). This function unloads all translations in the previous locale and loads the translations of WordPress in the new locale passed as argument. WordPress uses this function to send emails in the user language, for example, the new user notification email. Once the email is sent, the previous locale is restored with restore_previous_locale().
It』s however important to know that these functions don』t load the theme or plugins translations. This is why the plugins and themes need to load their own translations with load_plugin_textdomain() or load_theme_textdomain(). This should be done just after the call to switch_to_locale(). Alternatively, it』s possible to hook to the action change_locale fired each time switch_to_locale() and restore_previous_locale().
Step 1: Get the locale the email must be sent – possibly with get_user_locale() which returns the locale set in the user profile.
Step 2: Call switch_to_locale() .
Step 3: Call load_plugin_textdomain to load your plugin』s translations if you did not hook to change_locale.
Step 4: Construct and send the email, using usual internationalization functions such as __().
Step 5: Call restore_previous_locale()
Step 6: Call load_plugin_textdomain to load your plugin』s translations if you did not hook to change_locale.
See also the post about locale switching on Make WordPress Core.
How to
How to know the current language in the theme ?
WordPress provides at least two functions for the themes or plugins authors to know the current language:
get_locale() returns the WordPress locale in the format 'en_US'
get_bloginfo('language') returns the locale in the format 'en-US'
Note the difference between '_' and '-' in the two functions. You can have a look at the following forum topics:
Return the current language as variable for your template
How to translate/switch specific contents on templates
Additionaly, Polylang now provides the function 'pll_current_language' which can return either the language code, the locale or the language name.
How to make translatable user defined strings in my plugin or theme ?
You have to register strings on the admin side with the function 'pll_register_string' and display them on frontend with 'pll__' or 'pll_e'.
How to make my custom post types and taxonomies multilingual?
You must register your custom post type (or taxonomy) in a function hooked to the 'init' action as usual.
The user will have access to an option to enable languages and translations for the custom post type (or taxonomy) in the Polylang settings. You can however use the 'pll_get_post_types' or 'pll_get_taxonomies' filters to get full control on this.
How to query content in a different language than the current one?
Polylang does set the language of the theme based on the main query, but it is possible to query content in a different language. For example, you can display the list of the five most recent French posts on an English page. Your custom query just needs to add the 'lang' parameter.
Example:
12345$posts = get_posts( array( 'post_type' => 'post', 'lang' => 'fr', // use language slug in the query 'showposts' => 5,) );
This 'lang' parameter is not only available for posts but also for terms using the function 'get_terms' and comments using the function 'get_comments'.
How to query multiple languages?
Example:
12345$posts = get_posts( array( 'post_type' => 'post', 'lang' => 'de,fr', // query German and French posts 'showposts' => 5,) );
How to deactivate the current language filter?
Example:
12345$posts = get_posts( array( 'post_type' => 'post', 'lang' => '', // deactivates the Polylang filter 'showposts' => 5,) );
How to display links to posts translations within the loop?
Example:
1234
- $post->ID ) ); ?>
How to load the Polylang API for ajax requests on frontend ?
Polylang should automatically detect AJAX requests on frontend and load the current language. You can optionally set the 'lang' variable (with the language code) in the request (POST or GET) to load a specific language instead of the current language. The variable 'pll_load_front' which was necessary in old versions is useless since v1.4.
When Polylang does load the language?
There are two cases:
The language is set from the content: Polylang needs to defer the language loading and does it in a function hooked to the action 'wp' action with priority 5.
The language code is added to all urls (default): there is no need to defer the language loading and it is done as if Polylang were not active.
Due to the first case, plugin authors should not attempt to translate strings before the 'wp' action has been fired. Polylang provides a new action 'pll_language_defined' which is fired as soon as the language is defined. It works whatever the option chosen by the user to set the language.
How to give access to strings translations to non-administrators?
As the main purpose of the strings translations is to translate options, Polylang checks for the 『manage_options』 capability, which is assigned to administrators by default, to control the access to the strings translations table. You can modify the required capability with the following snippet:
12345add_action( 'admin_menu', function() { if ( ! current_user_can( 'manage_options' ) && function_exists( 'PLL' ) ) { add_menu_page( __( 'Strings translations', 'polylang' ), __( 'Languages', 'polylang' ), 'edit_pages', 'mlang_strings', array( PLL(), 'languages_page' ), 'dashicons-translation' ); }} );
Here the capability was changed to 『edit_pages』, which is assigned to administrators and editors by default. See the codex to discover which capability you can use to target other roles.