How to translate custom fields in WordPress

Make a list of every custom field and decide whether it contains language-specific content or shared data. Text, textarea, WYSIWYG, button labels, and short descriptions usually need translation. Numbers, dates, product IDs, images, and tracking codes usually stay the same.

Also check that your theme, block, or page builder actually reads the field. Translating a value will not make it appear if the template never outputs that field.

Open your multilingual plugin’s settings and make the relevant post type translatable, including any custom post type that stores the fields. Create or confirm the site languages before editing field values.

With WPML, the relevant controls are under WPML → Settings → Custom Fields Translation. Other multilingual plugins use different labels, but the same decision is required: the translated post must have its own language version.

Set text fields to Translate when each language needs different wording. Use Copy for values that must stay identical in every language. Use Copy once when the original value should be copied initially but edited separately later.

For repeater and flexible-content fields, decide whether the layout must remain identical. Copy keeps the structure synchronised; copy once allows a translation to have a different number or arrangement of rows. Set the behaviour of sub-fields as well.

Translate the field’s label and instructions separately from the value stored on a post. If you use ACF with WPML, send the relevant field group through the translation workflow. Select, checkbox, radio, and button-group choices also need their own translations because their labels are stored with the field definition.

Do not assume that translating a post will translate the field label automatically. Field labels commonly appear in string or field-group translation screens, while field values appear with the translated post.

Open a post, page, product, or custom post in the source language and create its translated version. Enter the translated values into fields marked Translate, check copied values, and save the translation. Repeat this for every content item that uses the fields.

For relationship, post-object, page-link, and taxonomy fields, check that the selected item also has a translation. A reference to the source-language object can otherwise produce the wrong title, URL, or taxonomy on the translated page.

Switch languages and check the rendered page, archive, search result, block, and page-builder template. If a value is missing, first check the field preference, the translated post, and the template code that reads the field. Clear page and object caches after changing translation settings.

Be careful with Copy once: later edits to the source value do not automatically update the translation. Options pages are another common failure point because global ACF settings are translated separately from posts and pages.

For an ACF-based site with many structured fields, Advanced Custom Fields Multilingual is the quicker route. It puts translation preferences alongside ACF field groups and supports translated labels, instructions, values, repeaters, flexible content, and options-page workflows.

Choose it when multilingual content includes structured fields and you want fewer separate settings screens. You still need to choose carefully between translate, copy, and copy once, then review the translated content on the front end.