Polylang 文档

Can I use my own flags for the language switcher?

Yes. You can use PNG, JPG or even SVG files and name them with the WordPress locale. For example, en_US.png.
Upload these files in the /wp-content/polylang/ directory.
Note: You have to create the directory yourself. Don’t use the /polylang/flags/ directory as your files would be removed when automatically updating the plugin. Alternatively, it’s possible to store the files in the /polylang/ subdirectory of the theme or the child theme.
Once the custom flags are uploaded, go to Languages > Settings. Click on the “URL modifications” settings and then on Save Changes.
Note: To specify the height and widh of SVG flags, you need to use the PHP filter pll_custom_flag.
Note: Your custom flags won’t be used on admin side. You can change them only with the PHP filter pll_flag.

I can’t add the language switcher in the menus

In Appearance >Menus, go to screen options on top right of your screen and check the “Language switcher” checkbox. You then should have a new metabox which allows you to add a language switcher the same way you add other menu items.
Due to WordPress limitations, it is currently not possible to add the language switcher from the Customizer Menus.

My menus disappeared when switching to another theme

The menu theme locations are theme dependant and are not kept when you switch to another theme. You must reassign them.

My menu doesn’t change with the language

A frequent issue is a menu which is correct when directly accessing the page but doesn’t switch when clicking on the language switcher. More and more themes are loading the content in Ajax and thus don’t reload the menu and content common to every pages (ex footer, widgets). This Ajax feature is obviously not compatible with multilingual websites. Try disabling the Ajax feature in your theme options or contact the theme support if you don’t find such option.

Is Polylang GDPR compliant?

Since the version 4.9.6, WordPress allows to export personal data. This includes the biographical info. As Polylang and Polylang Pro allow the users to translate their biographical info, the translations are added to the exported data since the version 2.3.6.
None of our plugins collect other personal data.

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);

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 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.

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.

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.