← Back to blog
Our WordPress plugins
September 26, 2026

ACF Translation Preferences in WPML: Copy, Translate, or Don’t Translate?

ACF Translation Preferences in WPML: Copy, Translate, or Don’t Translate?

A single ACF setting can quietly turn a polished multilingual site into a maze of missing text, repeated values, or broken relationships. The problem is rarely WPML itself—it is choosing Copy when a field needs its own language version, or choosing Translate for data that should never diverge.

If you are configuring custom fields for posts, products, landing pages, or connected content, wpml acf translation preferences copy translate is not just an admin-screen detail. It determines what editors see, what visitors receive, and whether every translated page still behaves as intended.

The right choice becomes clearer once you stop treating every field alike. A headline, a price, a reusable ID, and a relationship field may sit side by side in ACF—but each needs a very different translation rule.

How WPML ACF Translation Preferences Work

A field can look identical in every language while serving a completely different job behind the scenes. That is why WPML ACF translation preferences are not a cosmetic setting: they determine what happens to each Advanced Custom Fields value when WPML creates or updates a translated post, page, product, or custom post type. The practical question is simple: should this value stay shared, be localized, or be excluded entirely?

ACF Translation Preferences: Copy vs Translate Decision Table

What does Copy mean in WPML custom fields?

Copy transfers the source-language field value to every translation and keeps it synchronized on later updates. Choose it for data that must remain identical across languages, such as an SKU, a product ID, a tracking code, a map coordinate, a layout option, or a true/false setting. Copy is not a translation choice; it is a consistency choice. If an English product’s SKU changes from “AX-200” to “AX-201,” every language should reflect that same technical value.

When should you choose Translate?

Translate gives each language its own independently editable field value. It is the right setting for customer-facing text: a subtitle, feature list, call to action, author bio, product specification label, or localized description. Once translated, the French or German value can differ from the English source without being overwritten. This is the core distinction in wpml acf translation preferences copy translate: translated text needs editorial freedom, while shared data does not.

What are Copy Once and Don’t Translate used for?

Copy Once copies the original value only when a translation is first created. After that, translators can adapt it independently. It works well for a starting description, campaign text, or a field that is usually similar but may need market-specific changes.

Don’t Translate leaves the field out of WPML’s translation workflow. Use it for internal notes, temporary import data, editor-only controls, or source-language information that should not appear on translated versions. When in doubt, ask whether a visitor should see and understand the value. If not, it usually should not be translated.

ACF Translation Preferences: Copy vs Translate Decision Table

Use Copy for shared settings, IDs, and non-translatable data

The costly mistake is assuming an ACF field’s type decides its setting. It does not; its purpose does. Choose Copy when every language must use the identical value: product SKUs, tracking IDs, booleans, layout toggles, API data, and external URLs that do not change by market. Copy is also safest for image, post, or relationship fields when every translated page should reference the same asset or item.

Use Translate for visible marketing and editorial content

Set a field to Translate when visitors need to read it in their own language. This includes headings, descriptions, button labels, testimonials, localized links, SEO copy, and promotional messages. A “Book a demo” CTA may be a simple text field, but it is still customer-facing language—not a shared setting. In practical wpml acf translation preferences copy translate decisions, meaning beats field format every time.

Use Copy Once when translations need a reusable starting point

Copy Once is the middle ground: WPML copies the original value when a translation is created, then lets translators edit it independently. Use it for contact details that initially match but may become regional, campaign copy adapted for local offers, or calls to action that need market-specific wording later. It prevents blank fields without permanently locking translations together.

Use Don’t Translate for internal or translation-excluded fields

Choose Don’t Translate for data translators should never touch: editor-only notes, migration markers, temporary flags, cached values, and fields maintained by an import, integration, or custom code. If the value is operational rather than editorial, excluding it reduces clutter and avoids accidental overwrites. For sites already running WPML, LATW AI Translator for WPML can then focus AI translation on the fields that genuinely require localized content.

Recommended WPML Settings for Common ACF Field Types

Text, textarea, WYSIWYG, and link fields

A single incorrect preference can quietly publish the wrong language on an otherwise well-translated page. For visitor-facing text, textarea, and WYSIWYG fields, choose Translate: headlines, product descriptions, CTAs, and editorial copy must be localized rather than copied verbatim.

Links need more judgment. Use Copy when every language should point to one universal destination, such as a global support portal. Choose Translate when each language has its own landing page or regional campaign URL. Copy Once suits a starting URL that translators may later replace. This is the practical core of wpml acf translation preferences copy translate: classify the purpose of the data, not merely its field type.

Image, gallery, file, and media fields

Use Copy when the same logo, product photograph, or PDF serves every market. Choose Translate when assets themselves change: screenshots with localized interface text, country-specific brochures, or imagery tailored to a local audience.

Do not mistake the ACF preference for a complete media-localization process. Translated alt text, captions, titles, and replacement files still require a deliberate media translation workflow. A copied image may be correct visually while its accessibility text remains untranslated.

Relationship, post object, taxonomy, and repeater fields

For localized relationships, translate the connected posts, products, and terms first. Then set relationship, post object, and taxonomy fields to Translate so WPML can map each item to its language equivalent. Copying a relationship is appropriate only when the target is intentionally shared across languages.

Repeaters and flexible content layouts are containers, not a one-setting answer. Set the repeater or layout intentionally, then review every nested field: copy a shared icon, translate the accompanying text, and translate linked content where local equivalents exist.

True/false, select, date, number, and configuration fields

Copy is the sensible default for shared settings: layout toggles, dimensions, internal IDs, and universal limits should not drift between translations. Exceptions matter. Translate or independently manage values for country-specific availability, local event dates, currencies, regional prices, and select choices whose meaning changes by language or market.

How to Configure and Test ACF Translation Preferences in WPML

Set preferences in WPML’s Custom Fields Translation settings

A single incorrect setting can quietly break every future translation. In WordPress, open WPML → Settings → Custom Fields Translation, then search for the ACF field names used by your field group. Confirm that WPML can see both the parent fields and any nested repeater, group, or flexible-content subfields.

Apply the choice from your decision table: use Copy for shared technical values, Translate for visitor-facing text, and Don’t translate for values that should remain language-specific or empty. The practical rule behind wpml acf translation preferences copy translate is simple: translate meaning, copy structure, and avoid sending internal data to translators.

Translate one representative page before bulk updates

Do not validate settings on a minimal page. Choose one page containing the complete field pattern: headings, rich text, images with alt text, links, repeaters, and relationship fields. Create its translation in WPML’s Advanced Translation Editor, or use the manual workflow if that is how your editors work.

  • Check that translatable fields appear as translation jobs.
  • Verify copied values are present but not editable as translated text.
  • Review the translated editor and the public page, especially repeated rows, media, and links.

If you use LATW AI Translator for WPML after this setup, remember it requires WPML and follows WPML’s field configuration; it cannot correct a poorly classified ACF field.

Avoid the most common ACF and WPML configuration mistakes

Copying every field is the most common shortcut—and usually the wrong one. It leaves calls to action, captions, and editorial labels in the source language. Conversely, translating technical identifiers, CSS classes, API values, or layout keys can damage templates.

Also inspect nested subfields individually; setting a repeater parent does not remove the need to review its contents. When preferences change after translations already exist, retest a representative page rather than assuming old translations will update cleanly. Finally, a copied relationship field may still reference the original-language post. Confirm that linked content has a translation and that the translated page resolves to it correctly.

Make Each Field Serve Its Purpose

The right WPML ACF translation preferences—Copy, Translate, Copy Once, or Don’t Translate—come down to one question: should this value remain technically identical, or should a visitor encounter it in their own language? Use Copy for shared values, Translate for reader-facing text, Copy Once when a shared starting point may need local adaptation, and Don’t Translate for data that belongs behind the scenes. Set those rules before translating at scale, then review a few real pages in every language to make sure the experience matches the intent.

For established WPML sites, LATW AI Translator for WPML can help translate eligible post content and custom-field text within WPML’s existing workflow, using your own AI or translation-provider credentials. It is an add-on, so WPML remains the multilingual foundation—but with the right field preferences in place, automation can support consistency rather than spread the wrong value across every language.

Our WordPress plugins
Translate your WordPress site with AI
Pick the LATW plugin that fits how your site is built - a complete standalone multilingual system, or drop-in AI translation for the setup you already run.
LATW for WPML Add-on for WPML
LATW for WPML
Translate posts, pages, custom fields, builder content and strings 1400× cheaper than WPML's Automatic Translation - billed to your own API key.
→ Works with everything WPML supports
→ Gutenberg, WooCommerce, Elementor, Bricks
→ Yoast & Rank Math SEO fields
Read more →
LATW Multilingual Standalone
LATW Multilingual
Language switcher, clean URLs and full multilingual SEO in one package - no WPML or Polylang required. Pro adds AI translation on six engines.
→ Standalone - no WPML or Polylang needed
→ Switcher, clean URLs & full hreflang SEO
→ Free bilingual site; Pro adds AI translation
Read more →
← Back to blog