Use this skill when plugin or classic theme code needs to detect, list, switch, or route by Polylang languages.
\nPolylang's public API lives in wp-content/plugins/polylang/src/api.php. Prefer those functions over PLL()->... internals. The PLL() accessor exists, but the source itself says API functions are preferred because internals may change.
Polylang may be inactive, may not have languages yet, or may be running in admin/REST/CLI without a current language. Always guard public API use:
\nif ( ! function_exists( 'pll_current_language' ) ) {\n return;\n}\n\n$lang = pll_current_language();\nif ( ! $lang ) {\n $lang = pll_default_language();\n}\n\nif ( ! $lang ) {\n return;\n}\nDo not read $_GET['lang'] directly as your language model. Let Polylang define the current language, then read it through pll_current_language().
pll_current_language( $field = 'slug' ) returns the current language on frontend, the admin language filter in admin, and false if no current language exists. Useful fields include:
$slug = pll_current_language(); // e.g. \"en\"\n$locale = pll_current_language( 'locale' ); // e.g. \"en_US\"\n$name = pll_current_language( 'name' );\n$lang = pll_current_language( \\OBJECT ); // PLL_Language object.\npll_default_language( $field = 'slug' ) has the same field behavior and returns false if no default language exists yet.
Since Polylang 3.4, composite language term properties are accepted:
\n$term_taxonomy_id = pll_current_language( 'language:term_taxonomy_id' );\n$term_language_tt = pll_default_language( 'term_language:term_taxonomy_id' );\nUse composite fields only when you need SQL joins or taxonomy term IDs. For most code, use slugs.
\nUse pll_languages_list() for language lists:
$slugs = pll_languages_list();\n\n$locales = pll_languages_list( array(\n 'fields' => 'locale',\n) );\n\n$active_slugs = pll_languages_list( array(\n 'fields' => 'slug',\n 'hide_empty' => true,\n) );\nhide_empty removes languages without posts. hide_default is also accepted by the implementation even though it is not documented in the short API block.
Do not derive languages from installed .mo files or locales. Polylang languages are stored as language terms and carry URL, flag, ordering, active/default, and term property data.
Use pll_home_url( $lang ) for localized home URLs:
$url = pll_home_url( 'fr' );\nIf no language or links model is available, the function falls back to home_url( '/' ). Do not build URLs by concatenating /$lang/; Polylang supports query-arg, directory, subdomain, and domain modes.
For a rendered switcher:
\nif ( function_exists( 'pll_the_languages' ) ) {\n pll_the_languages( array(\n 'show_flags' => 1,\n 'show_names' => 1,\n ) );\n}\nFor custom markup, ask for raw data and escape output yourself:
\n$items = pll_the_languages( array(\n 'raw' => 1,\n 'echo' => 0,\n) );\n\nforeach ( $items as $item ) {\n printf(\n '<a href=\"%s\" lang=\"%s\"%s>%s</a>',\n esc_url( $item['url'] ),\n esc_attr( $item['locale'] ),\n ! empty( $item['current_lang'] ) ? ' aria-current=\"true\"' : '',\n esc_html( $item['name'] )\n );\n}\npll_the_languages() returns an empty string or empty array outside the frontend if the links model is not available.
Check whether Polylang manages a type before adding language-dependent logic:
\nif ( function_exists( 'pll_is_translated_post_type' ) && pll_is_translated_post_type( 'book' ) ) {\n // Language-aware code for the book CPT.\n}\n\nif ( function_exists( 'pll_is_translated_taxonomy' ) && pll_is_translated_taxonomy( 'genre' ) ) {\n // Language-aware taxonomy code.\n}\nTo opt in programmatically, hook early:
\nadd_filter( 'pll_get_post_types', static function ( array $types, bool $is_settings ): array {\n $types['book'] = 'book';\n return $types;\n}, 10, 2 );\n\nadd_filter( 'pll_get_taxonomies', static function ( array $taxonomies, bool $is_settings ): array {\n $taxonomies['genre'] = 'genre';\n return $taxonomies;\n}, 10, 2 );\nThe source comments explicitly say these filters must be added early: in plugins_loaded for plugins or directly in functions.php for themes. Polylang caches the translated type lists after after_setup_theme, so late filters can appear to work in settings but fail at runtime.
Use $is_settings if you want a type forced on but hidden from the Polylang settings UI:
add_filter( 'pll_get_post_types', static function ( array $types, bool $is_settings ): array {\n if ( ! $is_settings ) {\n $types['internal_doc'] = 'internal_doc';\n }\n return $types;\n}, 10, 2 );\npll_current_language() can be the admin language filter or false when \"all languages\" is selected.lang request parameter if present.false or safe fallbacks. Treat that as a real state, not an exceptional edge case.PLL()->curlang->slug without checking that PLL()->curlang is a language object.pll_current_language() returns a string. It can return false, int, array values, or a PLL_Language object depending on $field.\\OBJECT when requesting a PLL_Language object.polylang-object-translations to resolve translated post/term IDs or save translation groups.polylang-rest-headless for REST lang parameters and Pro REST fields.polylang-wc-compatibility for products, variations, orders, SKU uniqueness, and Woo REST.Local source checked against:
\nwp-content/plugins/polylang/src/api.phpwp-content/plugins/polylang/src/translated-post.php and translated-term.phpwp-content/plugins/polylang/src/switcher.phpwp-content/plugins/polylang/src/rest-request.phpwp-content/plugins/polylang/polylang.phpwp-content/plugins/polylang/src/api.phpwp-content/plugins/polylang/src/switcher.phpwp-content/plugins/polylang/src/translated-post.phpwp-content/plugins/polylang/src/translated-term.phpwp-content/plugins/polylang/src/filter-rest-routes.phpwp-content/plugins/polylang/src/frontend/choose-lang.php