Using Polylang with Custom Fields and Theme Options

Polylang is one of the most popular WordPress plugins for creating multilingual websites. While translating posts, pages, categories, and menus is straightforward, many site owners run into a common challenge: how to handle custom fields and theme options across languages.

If your website uses custom meta boxes, Advanced Custom Fields, page builder data, or theme settings such as headers, footers, contact details, and homepage sections, you need a clear strategy to make those elements multilingual. In this guide, you will learn how Polylang works with custom fields and theme options, what to translate, and how to structure your setup for better performance and easier maintenance.

How Polylang handles custom fields

Custom fields store extra information attached to posts, pages, and custom post types. Examples include subtitles, button labels, product specifications, event dates, or flexible content blocks. By default, not every custom field should be translated in the same way, so Polylang lets you define how each field behaves.

In a multilingual setup, custom fields generally fall into a few categories:

• Translatable fields such as headings, descriptions, and call-to-action text.
• Shared fields such as SKU codes, unique IDs, or layout settings that should stay the same across languages.
• Copied fields that should duplicate from the original language when a translation is created.
• Ignored fields that are internal and do not need language-specific handling.

The key to success is deciding which fields contain language-dependent content and which fields are purely structural. For example, a hero title should be translated, but a background color setting probably should not.

Choosing the right translation behavior

When configuring Polylang with custom fields, review every field used by your theme or plugins. Text-based fields usually need translation, while numeric values, toggles, or design settings often remain identical across languages.

A practical example:

• Headline: translate it.
• Button text: translate it.
• Button URL: translate it if it links to a translated page.
• Section background image: keep or copy it if the same media is used.
• Layout option: copy it.

This approach prevents missing content in translated pages and avoids unnecessary duplication of technical settings.

Using Polylang with Advanced Custom Fields

Many WordPress sites rely on ACF for flexible page content. Polylang can work well with ACF, especially when each field group is designed with translation in mind. If your fields contain user-facing text, mark them for translation. If they control structure only, keep them synchronized.

For example, an ACF group for a homepage section may include a title, intro text, button label, image, and display style. In this case, the title, intro text, and button label should be translated. The image may be shared or replaced by language-specific media, depending on your content strategy. The display style should usually be copied.

It is also wise to keep field names consistent and descriptive. Clean naming conventions make multilingual maintenance much easier, especially on larger sites with many editors.

Managing multilingual theme options

Theme options are different from custom fields because they are often global settings rather than content tied to a single page. Common examples include the site-wide announcement bar, footer text, contact information, social media labels, and default homepage blocks.

The challenge is that many themes store these settings in a single options panel that is not automatically language-aware. If the theme was not built specifically for multilingual support, changing a value in one language may overwrite it for all languages.

To handle this well, you have several options:

• Use language-specific pages instead of global options for content-heavy sections like homepage banners or footer callouts.
• Store translatable strings through Polylang string translation when the theme registers them properly.
• Create separate options per language if your theme or custom development supports language-based option keys.
• Move important translatable settings into custom fields attached to translated pages or templates.

In many cases, the best solution is to avoid placing large amounts of visible text in a theme options panel. Instead, use translated pages, reusable blocks, or custom post types that Polylang can manage more naturally.

What should go in theme options

Theme options work best for settings that are global and mostly language-independent. These may include logo dimensions, layout preferences, color schemes, tracking code placement, and technical integrations. For multilingual text, use options only if your theme is fully compatible with Polylang string translation.

A good rule is simple: if visitors read it, it probably needs a translation workflow. If it controls appearance or behavior, it may belong in theme options.

Best practices for a stable multilingual workflow

Combining Polylang, custom fields, and theme options can become complex quickly, so structure matters. A few best practices will save time and reduce errors as your site grows.

• Audit your fields first and classify them as translatable, copied, shared, or ignored.
• Keep content separate from design settings so translation decisions are easier.
• Use translated pages for major content sections instead of storing long text in global options.
• Test every custom post type and template before launching additional languages.
• Check internal links in custom fields to ensure they point to the correct translated content.
• Document your setup so editors know which fields require translation.

You should also test the front end thoroughly. A field may appear correctly in the WordPress dashboard but still output the wrong language if the theme template is not coded to retrieve the translated value properly.

Common issues to watch for

Some multilingual problems are not caused by Polylang itself but by how themes or plugins store data. Watch for these common issues:

• Serialized field data that does not translate cleanly.
• Hardcoded theme strings that are not registered for translation.
• Global options panels that overwrite values across languages.
• Custom queries that ignore language filters.
• Buttons and links that still point to the default language.

If you run into these issues, the solution may require theme customization or help from a developer familiar with multilingual WordPress projects.

Final thoughts

Using Polylang with custom fields and theme options is absolutely possible, but it works best when you plan your data structure carefully. Translate user-facing content, copy structural settings, and avoid placing important multilingual text in theme options unless the theme supports it properly.

For many websites, the most reliable setup is to use Polylang for translated posts, pages, and custom post types, while keeping theme options limited to global technical settings. That approach gives you cleaner translations, fewer sync problems, and a much easier editorial workflow.

If you are building or redesigning a multilingual WordPress site, start by mapping where every piece of content lives. Once you know whether each item belongs in a post, a custom field, or a theme option, Polylang becomes much easier to manage.

Learn more about Polylang on WordPress.org.