How Polylang free and ACE ACF | Multilingual Custom Fields free works together11.12.25

A practical, developer-focused guide to using Polylang (free) with Advanced Custom Fields (ACF, free).
    Patterns and helper functions for: post fields, term fields, options (site-wide settings), and registering ACF values as translatable strings.
    Key Polylang functions to use and pitfalls to avoid.

High-level rules

ACF post meta lives on each post. When you create translations of a post, each translated post has its own postmeta — so per-post ACF fields are naturally per-language.
    For everything else (term meta, options, strings) you must explicitly read/write the language variant or register the string for translation.
    Polylang Pro adds nicer integration features; with Polylang free you manage language-specific storage/lookup yourself.

Useful Polylang functions (free)

pll_current_language() — returns current language slug (e.g. 'en', 'fr').
    pll_default_language() — default language slug.
    pll_get_post($post_id, $lang) — get translated post ID in $lang.
    pll_get_term($term_id, $lang) — get translated term ID in $lang.
    pll_register_string($name, $string, $group = '') — register a string to translate in admin > Languages > Strings translations.
    pll__($string) — return translated string (like __()).
    pll_the_languages() — output language switcher.

Post-based ACF fields (recommended: default flow)

When you translate a post in Polylang, the translated post gets its own postmeta. Use get_field()/the_field() as usual inside the loop — they will return the value for the current post/language.
    When you need to pull a field from the other language (for example, to show a fallback or build a language switcher), use pll_get_post() to find the translated post ID then call get_field() against it.

Example: get field from specific language (post)
PHP

function get_acf_field_in_lang( $field_name, $post_id = null, $lang = null ) {
    if ( ! function_exists( 'pll_current_language' ) ) {
        return get_field( $field_name, $post_id );
    }

$lang = $lang ?: pll_current_language();
    $post_id = $post_id ?: get_the_ID();

// If already in requested language and post_id is correct
    $translated_id = pll_get_post( $post_id, $lang );
    if ( $translated_id ) {
        return get_field( $field_name, $translated_id );
    }

// Fallback: try original post
    return get_field( $field_name, $post_id );
}

Usage:

get_acf_field_in_lang('subtitle') — returns subtitle for current language post.
    get_acf_field_in_lang('subtitle', $post_id, 'fr') — returns subtitle from French translation of $post_id.

Term (taxonomy) ACF fields

Term meta is stored keyed by term. Use pll_get_term() to get the translated term id and then get_field with a term context.

Example: get ACF field for term in a language
PHP

function get_term_acf_field_in_lang( $field_name, $term_id, $taxonomy = 'category', $lang = null ) {
    if ( ! function_exists( 'pll_get_term' ) ) {
        return get_field( $field_name, "{$taxonomy}_{$term_id}" );
    }

$lang = $lang ?: pll_current_language();
    $translated_term = pll_get_term( $term_id, $lang );
    if ( $translated_term ) {
        return get_field( $field_name, "{$taxonomy}_{$translated_term}" );
    }

return get_field( $field_name, "{$taxonomy}_{$term_id}" );
}

Note: ACF uses the {taxonomy}_{term_id} context when reading/writing term meta.

Options / ACF Options Page (site-wide settings) Polylang free does not provide a native multilingual options page. Common strategies:

Create language-specific option keys (e.g., 'my_options_en', 'my_options_fr').
    Store option values as an array keyed by language: update_option('site_options', ['en' => [...], 'fr' => [...]]).
    Use ACF but save options per language by using language-aware option IDs.

Example: language-aware wrapper for ACF options
PHP

function get_acf_option_in_lang( $field_name, $lang = null ) {
    if ( ! function_exists( 'pll_current_language' ) ) {
        return get_field( $field_name, 'option' );
    }

$lang = $lang ?: pll_current_language();

// Approach A: ACF supports custom $post_id for options. We use "option_{$lang}" as a unique id.
    $option_id = "option_{$lang}";

// Try ACF get_field for this language-specific option
    $value = get_field( $field_name, $option_id );
    if ( $value ) {
        return $value;
    }

// Fallback to default 'option'
    return get_field( $field_name, 'option' );
}

When saving options via code, use update_field( $field_name, $value, "option_{$lang}" ). For forms in WP-Admin you can create separate ACF options pages per language (e.g. add_options_page with slug suffixed by language), or use a dropdown to switch the language and save to the corresponding option id.

Registering ACF values as translatable strings (good for short strings)

For small pieces of content (single-line values) that you want to translate with Polylang’s Strings translations UI, register them with pll_register_string() and then use pll__()/pll_e() when printing.

add_action( 'acf/save_post', function( $post_id ) {
    // Only do this for options page saves; ACF options use post_id 'option'
    if ( $post_id !== 'option' ) {
        return;
    }

if ( ! function_exists( 'pll_register_string' ) ) {
        return;
    }

// Example: register a phone string
    $phone = get_field( 'company_phone', 'option' );
    if ( $phone ) {
        pll_register_string( 'company_phone', $phone, 'ACF Options' );
    }

// Register other fields as needed...
}, 20 );

Then when outputting:
PHP

$phone = get_field( 'company_phone', 'option' );
echo pll__($phone); // will output translated string if set

Important: pll_register_string registers the string (original text). Translators in admin fill translations per language. This works best for atomic strings, not large HTML/text fields.

Syncing custom fields on translation creation

Polylang has synchronization settings (in admin > Languages > Settings > Synchronization) to control what to copy when creating translations. If you want certain fields to be copied auto-when creating a translation (for example, a layout meta you want identical), consider adding the custom field key to the synchronization list.
    If you need custom behavior on translation creation, hook into the Polylang action that runs when a translation is created (check current Polylang docs for actions like pll_copy_post_metas or similar) and copy specific meta manually.

Relationship / Post object fields

Relationship/ post object fields store post IDs. For cross-language behavior, store the ID for the same language post. If you want a relationship to point to a translated post when viewing another language, resolve IDs with pll_get_post().

Example: resolving related posts to current language
PHP

$related = get_field( 'related_posts' ); // might be array of post IDs in original language
if ( $related && function_exists( 'pll_get_post' ) ) {
    $lang = pll_current_language();
    $translated_related = array_map( function( $id ) use ( $lang ) {
        $tr = pll_get_post( $id, $lang );
        return $tr ? $tr : $id;
    }, (array) $related );
    // use $translated_related
}

Practical patterns & checklist for developers

Prefer per-post ACF fields for translatable content — they are naturally per-language.
    When you need to show ACF content for another language (or build a language switcher preview), use pll_get_post/pll_get_term to find the translated ID and fetch with get_field.
    For options, pick one strategy and be consistent: language-specific option keys (recommended) or array by language.
    Avoid echoing ACF values without escaping; use esc_html/wp_kses_post as appropriate.
    Test: translate posts, create translations of terms, and ensure relationships point to the correct language.
    If you want translators to edit some ACF values, either register them as strings (pll_register_string) or build language-specific option pages.

Pitfalls & gotchas

ACF the_field() will echo raw content; always escape when outputting user-supplied content.
    Polylang free won’t automatically create language-specific option pages for you.
    Some ACF field types are complex (arrays), so registering them as a single string for Polylang Strings translation is not recommended.
    If you use plugins or code that clones postmeta between translations, be careful not to copy language-specific text you want localized.

Concrete examples (short)

Show post field in current language: the_field('subtitle');
    Show same field but from French translation: echo get_acf_field_in_lang('subtitle', get_the_ID(), 'fr');
    Get translated term field: echo get_term_acf_field_in_lang('term_intro', $term_id, 'category', 'de');
    Language-aware option example: echo get_acf_option_in_lang('company_phone');

What I did here and next steps

I explained the recommended approaches and provided reusable helper functions/code patterns you can drop into your theme or plugin.
    Next, I can:
        Produce a small, copy-paste-ready library (single PHP file) with these helpers plus admin UI helpers to manage language-specific ACF options pages.
        Generate specific code for your site if you tell me which ACF fields you need multilingual (post fields, term meta, options, relationships).
        Show how to automatically register some ACF option fields as Polylang strings on save (example expanded).

https://www.advancedcustomfields.com/resources/multilingual-custom-fields/

Anonymous

How Polylang free and ACE ACF | Multilingual Custom Fields free works together11.12.25

Information Epoch 1774120420