Detect the browser preferred language

Detect the browser preferred language

Go in Languages > Settings
Note that this option works when the language is chosen from the content, from the directory name in the url or from the subdomain. You need Polylang Pro and SSL for it to work when you use multiple domains.

When activated, someone visiting your homepage for the first time is redirected to the homepage in the language according to his browser preferences. If his browser preferences do not include any language of your site, the default language is used.
Polylang sets a cookie for returning visitors to be redirected to the homepage in their last browsed language. Thus, if you want to test the functionality on your site, don』t forget to clear your cookies between each test.
Here are some examples with French as default language:

Case 1: None of the browser language preferences of your visitor match the website languages. The visitor is redirected to the French home page (default language). If his last browsed page is in English, he will be redirected to the English homepage at the second visit.

Cases 2 & 3: In both cases, English is the first language in the browser preferences of your visitor which matches one of your website languages. The visitor is redirected to the English home page.
Note: If you don』t want any redirection to occur, you must deactivate the browser preferred language detection and hide the default language code in URLs by checking the relevant option in the URL modifications settings.

What is the duration of a license key?

What is the duration of a license key?

A license key is necessary to obtain the automatic updates and to access to the helpdesk support.
A license key is valid for one year as from the date of purchase. It may be renewed after one year at a preferential rate (currently 50% of the new license price). If a key is not renewed prior to its expiration, the plugin will continue to operate but you will no longer have access to automatic updates and helpdesk support.
It is recommended to run the latest version of WordPress, your theme and your plugins.

The language switcher

The language switcher

Add a language switcher

Add a language switcher in a menu
Add a language switcher as a widget with legacy block
Add a language switcher as a widget in the new block editor
Add a language switcher anywhere

Options

Displays as dropdown
Displays language names and displays flags
Force link to front page
Hide the current language
Hide languages with no translation

Customizing language names
Customizing flags

Use a flag from the predefined list
Use a custom flag

Order of languages

The purpose of the language switcher is to create links to the translations of your current page. By default, if the current page is untranslated, the language switcher links to the front page in the corresponding language.
Note: To avoid 404 errors, the language switcher does not display a language on the front end if there is no published content (post or page) in that language. If there is no content in any language, then the language switcher does not appear at all.
1. Add a language switcher
1.1 Add a language switcher in a menu
You can include the Polylang language switcher in your menu. If you don』t see the language switcher metabox, check that it is not disabled in the screen options (horizontal tab which can be unfolded as shown by bullet 3 in the 「Menu」 documentation).
Refer to Options for the detail of what each option of the Language Switcher does.

1.2 Add a language switcher as a widget with legacy block
With Polylang you have the possibility to add our widget Language switcher, in the Appearance tab > Widgets sub-tab, by first adding a block 「Legacy Widget」 in which you then select the Polylang Language Switcher.
This option works with Polylang Pro for existing widgets only, it is no longer possible to add it. The block must be used instead.
Refer to Options for the detail of what each option of the Language Switcher.
You can choose to display either the language name or its flag or both
1.3 Add a language switcher as a Block in the new widgets block editor
With Polylang Pro you have the possibility to add a language switcher in the new widget block editor introduced in WordPress 5.8. To do so simply search for 「Language Switcher」 in the search form of the block editor in your Appearance tab > Widgets sub-tab.
Click on the icon of the block, it will add it to the main blocks list (central scroll zone) and open the block editor embedded view in witch you』ll find all the 「Language Switcher」 options.
Refer to Options for the detail of what each option of the Language Switcher.

1.4 Add a language switcher anywhere
You can include a language switcher anywhere in your site by using the PHP template tag pll_the_languages().
2. Options
By default the language switcher will display languages names only. You can easily change the configuration using the available options detailed below.
2.1 Displays as dropdown
Dropdown with Twenty Twenty One theme
If you choose this option for the widget, it is not possible to display flags due to html limitations. It is however possible to work around this limitation with javascript (not provided by Polylang). There is no such limitation when using this option in the menu.
2.2 Displays language names & Displays flags
In the examples below (with the Twenty Twenty One theme), you can see the result when both settings have been checked for the language switcher :

In a menu

In a widget

2.3 Forces link to front page
You have the possibility to always link to the front page in the corresponding language even if the current page is translated.
2.4 Hide the current language
Choose this option  to never display the current language.
For example, if your home page is translated in three languages (English / Italian / French). When viewing the English home page the language switcher will only display Italian and French. You then click on French (Français in the gif), the language switcher will display English and Italian as available languages to switch to.

 
2.5 Hide languages with no translation
If, for example, the current English post is not translated in Italian, the language switcher doesn』t display any link for Italian.
3. Customizing language names
You can change the language name by modifying the full name of the language.
4. Customizing flags
4.1 Use a flag from the predefined list
You can choose your language flag among all the flags when creating or editing a language. This flag is used on both frontend and admin sides.
4.2 Use a custom flag
It is possible to use your own images as flags. You have to use PNG or JPG files and name them with the WordPress locale. For example, en_GB.png. Then upload this file in the /wp-content/polylang/ directory (create the directory if it does not exist). Don』t use the /polylang/flags/ directory as your file would be removed when automatically updating the plugin.
Once the custom flag is uploaded, go in Languages > Settings > URL modifications module then click on save changes. Note that your custom flags are not used on admin side.
Developers can also access more options by using the filter pll_custom_flag
5. Order of languages
You can choose the order of the languages in the language switcher when creating or editing a language.

Product CSV Importer and Exporter

Product CSV Importer and Exporter

The WooCommerce CSV importer and exporter are supported by Polylang for WooCommerce.
Importer
You need to use WooCommerce 3.2 or later. Your CSV file must contain one row per product and per language. It』s however possible to use multiple files, for example one file per language.
Configure the CSV file
Your CSV file contains a list of product and their translations and you need to identify the language of each row, and which rows are the translation of each others. To achieve this you need to create a 『Language』 and a 『Translation group』 column.

Language: you must specify the language code. You can find it in languages list table, column 『Code』.
Translation group: you must specify a value which identifies to which translation group this product belongs. This value must be unique to the translation group.

In the example below, we import one product in 3 languages. All rows which are the translation of each other are sharing the 』20』 value.

As shown below, you can use the SKU as unique translation group. As WooCommerce imposes to use one column per field, you need to copy your SKU values and paste them in the Translation group column. Be careful: as opposed to the SKU there isn』t any warning if you reuse an existing identifier for the translation group.

If you want to use one file per language, you need also to create a 『Language』 column and a 『Translation group』 column. This will allow to identify which row from one file is the translation of the other rows in the other files.
For example below is a CSV file which contains English products:

And another file with its French translations:

Import the CSV file
Once you have correctly created your CSV file, you can run the WooCommerce importer. In the Mapping screen, assign the 『Language』 and the 『Translation group』 fields to your corresponding colums and run the importer.

Exporter
When exporting products, you can choose to add the 『Language』 column and the 『Translation group』 column as shown below:

Here is an example where we exported one product available in 3 languages. We get one row per product and per language. All rows which are the translation of each other are sharing the same translation group.

Single sign on across multiple domains

Single sign on across multiple domains

The single sign on (SSO) feature, available in Polylang Pro only,  allows you to be automatically logged in across multiple domains or subdomains. Here are some situations where this feature is useful:

You are able to preview translated posts in context. Without SSO, previews are displayed on the main site.
You can see visit pages in a deactivated language (when logged in with sufficient privileges). Without SSO, deactivated languages are not visible.
The admin bar is displayed on all domains (or subdomains). Without SSO, the admin bar is displayed only on the main site.

How it works?
Let』s say that you are logged in on en.mysite.com and you want to visit fr.mysite.com. You click on the link to the French translation in the language switcher and:

The French page is first  displayed without you being logged in. The admin top bar is not displayed.
Polylang automatically redirects you on the same French page with you being logged in. The admin top bar is displayed.

Of course, the redirection does not occur for the next pages you will visit in the same domain or subdomain.
Notes:
When using multiple domains, this feature requires SSL.
Logout is automatically done on all domains or subdomains at the same time.
Polylang is not able to automatically sign you inside the customizer.

Do I need another license key for staging sites and localhost?

Do I need another license key for staging sites and localhost?

No. You can buy only one license key per public site and use it for localhost and your staging site. Your test site url has however to match:

localhost
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
*.dev
*.local
*.test
dev.*
staging.*
sandbox.*
*.wpserveur.net
*.wpengine.com
*.wptiger.fr

All urls matching the rules above will not be counted against your limit of sites. If you have any problem, please contact our support.

Multilingual Custom Post Types and Taxonomies

Multilingual Custom Post Types and Taxonomies

Go to Languages > Settings
Click on the settings link of the Custom post types and Taxonomies module. Below is an example displaying a custom post type 『Book』 and its custom taxonomy 『Genre』. The checkboxes allow you to choose whether to enable the languages and translation management for these post types an taxonomies.

Note: To correctly display the languages columns and metabox for custom post types and taxonomies, plugins or theme authors must use the same actions and filters as WordPress. Otherwise there is now way for Polylang to add its own interface.
Note for developpers: By default, Polylang displays the post types and taxonomies in the settings for which the parameter 『public』 is set to true. Other won』t appear. You can use the wpml-config.xml file or the filters 『pll_get_post_types』 and 『pll_get_taxonomies』 to change that.

Managing orders

Managing orders

Orders are assigned a language, allowing  emails sent to the customer to be in this language.
Note: the emails are translatable in the Strings translation panel.
The language information is provided, for example, to allow the shop owner to send order notes in the customer』s language. When the admin language filter is not activated and displays 『Show all languages』, all orders in all languages are visible.

If you are in charge to treat the Spanish orders, activate the admin language filter with 『Spanish』. You will see only the orders in Spanish and the language column won』t be displayed anymore.
When editing an order, the language is visible in a metabox which allows you to send your order notes in the customer』s language.

Working with ACF Pro

Working with ACF Pro

The compatibility with ACF Pro is provided by Polylang Pro. This integration is available only for post types and taxonomies. It does not work yet for options pages (this is planned for a future version). There is however an integration contributed by the Be API Agency to achieve that, see: https://wordpress.org/plugins/acf-options-for-polylang/.

Before you start
Translating Fields Groups

Activate Fields Groups Translation
Translate a Fields Group

Translating fields values

Customize ACF fields behavior

Ignore
Copy once
Translate
Synchronize

With translated values
With copied values

The WPML configuration file

1. Before you start
The first question to ask yourself is: 「Do I need to translate the label and the instructions?」

If yes, thus you need to translate your field groups in all your languages, you should read 2. Translating Fields Groups (see below). If not, it is preferable not to translate your field groups, you can skip to 3. Translating the fields values.
2. Translating Fields Groups
2.1 Activate the Field Groups translation
Go to Languages > Settings > Custom post types and Taxonomies and activate the translation as shown here:

2.2 Translate a Field Group
Go to Custom Fields > Field Groups.
As you see in the following screenshot, the field groups are now translatable. Before translating your field groups you need to activate the duplicate tool as below, it will allow you to copy all the content from the source field group to the translation.

We recommend you to create entirely your field group with the wanted custom fields before translating it. Indeed there is no synchronization between the translated field groups. It means that a modification made for example in the English field group won』t impact its French translation.
Once you have duplicated your field group into another language, you just need to edit new field group to translate the label and the instructions.
Important note: You must not modify the field name value across your translations. You must keep the same value.
3. Translating fields values
3.1 Customize ACF Pro fields behavior
Since Polylang Pro 2.7, you have the ability to fine tune how your ACF Pro fields will behave when you create new translations for your posts (and pages, and custom post types…). This happens directly in ACF Pro』s Custom Fields sub-menu (see picture below).

There are four options:
3.1.1 Ignore
When creating a new translation, each custom field for which you have selected the 『ignore』 option will be left blank in the newly created translation.
3.1.2 Copy once
When translating a content (post, page, taxonomy …) in another language, Polylang decides which custom fields must be copied and which ones must be automatically 『translated』. The custom fields that will be translated are:

image
file
gallery
post object
relationship
page link
taxonomy.

It means that Polylang prefills the field with the correct value when creating new translations. For example, if an 『image』 custom fields is translated, Polylang will try to find the translation of the linked image, if it exists. This also works when these custom fields are included in repeater fields. If the translation doesn』t exist, Polylang will keep the value as is.
3.1.3 Translate
This is very similar to 『copy once』, although these fields are expected to be translated after the translation has been created. We suggests that you choose this option for each custom field you intent on translating yourself, or through a translation service (whether manual or automatic).
This option is only available for the following fields:

Text
Text area
WYSIWYG editor

3.1.4 Synchronize
As a reminder, 『synchronization』 means that a modification made in a content impacts all its translations. So after creation of a translation, and when the post (or page, or taxonomy, etc.) is modified the custom fields marked for 『synchronize』 will then behave differently given of the kind of value you want to modify.
3.1.4.1 With translated values
If you decide to modify a translated value from a synchronized custom field, Polylang will automatically synchronize the custom field of all the other translations. In the example below we set the English value of a post object field to 「A post in English」. As you can see in the following screenshot its translated French value 「Un article en Français」 is automatically copied to the translated French post.

3.1.4.2 With a copied value

If you modify a copied value (text, number, email, url custom field …) in a synchronized custom field, Polylang will automatically keep this same value in the translated English post.
A modification made on the layouts (group, repeater, flexible content) will impact the translations. For example, if you choose to add a flexible content in a French post, Polylang will automatically add this flexible content to the translated Englih post. It』s the same behavior if you decide to remove it.
Note: These options are not available for 『Layout』 type of custom fields, but each sub-field can be customized on its own.
Important Note: Even if you have selected the custom fields synchronization option in Languages > Settings > Synchronization (see section Custom fields outside of ACF Pro ), the options you select for each ACF Pro custom field will override this synchronization.
4. The WPML configuration file
Alternatively, you can configure the way each custom fields behave when a content is translated by writing a wpml-config.xml file. Each custom field you add to this configuration file will override the behavior selected in the Custom Fields sub-menu. Also the wpml-config.xml applies to every custom fields from every plug-in, as well as those you added manually. See our documentation: The wpml-config.xml file

What is covered by the support?

What is covered by the support?

Per our general terms and conditions of sale, the support includes the assistance with the installation and use of our plugins. It of course includes the correction of bugs. It does not include the resolution of conflicts with theme or third party plugins. It does not include writing personalized code to fix a problem. It does not include reviewing or fixing personalized code written by the client. No support will be due in the event of a modification of the plugin by the client.