How to uninstall Polylang?

How to uninstall Polylang?

There are two things to understand when uninstalling or removing Polylang or Polylang Pro.

If you deactivate and delete the plugin from WordPress, you only remove the plugin and its files. Your settings, languages and information linking translations together will still exist in the database.
If you need to remove ALL Polylang data, including languages, settings, etc., you need to be able to modify the site’s wp-config.php file before deactivating and deleting the plugin.

To fully remove all Polylang data from your WordPress site, open your site’s wp-config.php file. Add define( ‘PLL_REMOVE_ALL_DATA’, true ); on its own line above the /* That’s all, stop editing! Happy publishing. */ line.
Then when you deactivate and delete Polylang or Polylang Pro it will remove all of its data from your WordPress site database.

My theme or some plugin is not translated

My theme or some plugin is not translated

There are two main reasons for this to occur:

Your theme or plugin may not be translated (no or incomplete .po/.mo files). You can use poedit the plugin Loco translate to make the translation.
Your theme or plugin may not be compatible with the Polylang option “The language is set from content”. Try using the default setting: “The language is set from the directory name in pretty permalinks“.

Google reports errors about hreflang attributes

Google reports errors about hreflang attributes

You create one page in a first language and you publish it. Google crawls the page displayed without hreflang attributes because the page is not translated yet.
Later, you translate the page in a second language and publish the translation. Google crawls the translation and finds hreflang attributes since the page is translated. Google has crawled the first page and its translation and reports an error about hreflang attributes not matching.
Even later, Google crawls the first page again and finds the hreflang attributes. They are matching the hreflang attributes of the translated page. Google doesn’t report the error anymore. Please be patient. It can take time for Google to crawl your original page after you translated it.
You would have the same error if you originally have a page in several languages and add later an additional translation. In this case, the error may be reported during even more time as all translations must be crawled by Google before it removes the error.

The random header image of Twenty Eleven does not work

The random header image of Twenty Eleven does not work

Most probably you uploaded the images and did not translate them. You have to either translate the images in all languages or de-activate the languages and translations management of media in Polylang settings.

Widget titles are not listed in the strings translation table

Widget titles are not listed in the strings translation table

If you enter a title in the widget options and this title is not listed in the translation table, it is most likely because the widget uses the very old Widget API (WP < 2.8). Obviously the advantage for the widget is to be compatible with WordPress older than 2.8 but unfortunately, there is no way to make Polylang automatically compatible with all widgets which use this old API.
It is however possible to make them compatible for people who have some PHP skills, using the Polylang API functions ‘pll_register_string’ and ‘pll__’.

A widget has no multilingual capability

A widget has no multilingual capability

WordPress 2.8 introduced a new widget API. Polylang is compatible with this API. Any widget which is compatible with older versions of WordPress should still work but will have no multilingual capability (no possibility to display it in only one language, no possibility to translate the widget title). Of course, all default widgets are supported by Polylang.

The characters are not correctly encoded

The characters are not correctly encoded

1. Open the the wp-config.php in the WordPress root directory and check that the DB_CHARSET is defined to UTF8:
12/** Database Charset to use in creating database tables. */define(‘DB_CHARSET’, ‘utf8’);
2. Go in your database and check that the charset of your database and all your tables is UTF8:

If everything looks OK but the problem is still there, we recommend that you report your issue on the specific language forum to know how native speakers handle these characters.

My theme provides a wpml-config.xml but nothing appears in the Strings translation table

My theme provides a wpml-config.xml but nothing appears in the Strings translation table

This issue could occur with child themes when the parent theme stores its options in theme mods.
In that case, edit the wpml-config.xml file provided by your parent theme, and change the line:

to

Then put this new wpml-config.xml file into your child theme’s directory, or in /wp-content/polylang/. You must create the directory if it does not exist.

How to translate emails?

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.

Function reference

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’