Control What WPML Translates - Post Types, Custom Fields, Media, Taxonomies

Every Translatable Thing Has One of Three States

Every translatable thing on your site has three possible states:

Translatable. WPML treats it as content that should exist in every language. It appears in the Translations Dashboard and in your translators’ queues.
Translatable with a fallback. The same, but when a translation is missing, WPML shows the source-language version instead of hiding the item.
Not translatable. WPML ignores it. Doesn’t appear in Translations anywhere.

The default for built-in WordPress content (Posts, Pages, Categories, Tags, Media) is Translatable. Plugin-registered content types (custom post types, custom taxonomies) default to Not translatable. Flipping them on is often the first thing a new site does after install.

For custom fields and term meta, you have four states instead of three (see below).

Everything that follows lives at WPML > Settings.

Post Types

Settings > Post Types Translation.

Every post type registered on your site appears in the list – Posts, Pages, Media (as attachment), Custom CSS, plus every CPT your themes and plugins have registered. Per type, pick:

Translatable – only show translated items. The default for Posts and Pages.
Translatable – use translation if available or fallback to default language. When the translation is missing, the source-language version shows in the target language. Useful for reference content that doesn’t need full localisation.
Not translatable. WPML ignores it.

A custom post type defaulting to Not translatable is the #1 reason a CPT doesn’t appear in the Translations Dashboard. If you’ve added a CPT and can’t find it in Translations, this setting is the first thing to check. Once a type is set translatable, Translating posts, pages and custom post types covers how to send it for translation.

Taxonomies

Settings > Taxonomy Translation.

Same three options as post types, applied to taxonomies. Built-in Categories and Tags default to Translatable – only show translated items. Custom taxonomies (product categories, brands, regions) often default to Not translatable; flip them on if you want their terms translated.

For how taxonomies get translated, see Translating taxonomies. This page is about whether they’re translatable in the first place.

Custom Fields

Settings > Custom Fields Translation.

Custom fields are post metadata – anything stored as post_meta in the database. Themes and plugins store all kinds of data there: download links, ratings, prices, layout choices, structured content. WPML lists every custom field key on the page; per field, pick one of four behaviors:

Don’t translate. WPML leaves the field alone. The value isn’t copied, isn’t translated. Translations get an empty field. The default for most fields a plugin registers.
Copy. WPML copies the source-language value to every translation, and re-copies on every edit. The translation’s field always matches the source. Use for fields where the value is structural (a layout choice, an internal ID) and shouldn’t differ per language.
Copy once. WPML copies the source value to translations when they’re first created, but doesn’t re-copy on subsequent edits. Use when you want a starting point that translators can override per language but don’t want changes to the source to overwrite their work.
Translate. The field enters the Translation Editor. Translators see and translate it like body content. Use for any field whose value is human-readable text.

The difference between Copy and Copy once is the most-asked question about custom-field translation. Copy keeps the value in sync forever; Copy once doesn’t propagate later edits. Pick Copy when the field is a structural reference; pick Copy once when translators may need to customize per language.

SEO plugins (Yoast SEO, Rank Math, All in One SEO) register their own custom fields here; How to translate your site for multilingual SEO covers how WPML translates SEO meta titles, descriptions, and term meta alongside post content.

For sites where developers want to declare custom-field defaults in code instead of the admin UI, Custom wpml-config.xml is the format themes and plugins ship to set their own defaults – and the layer you can paste a site-specific override into at Settings > Custom XML Configuration.

Custom Term Meta

Settings > Custom Term Meta Translation.

Same four-option model as custom fields, applied to taxonomy term metadata. Most sites don’t use much term meta, but some do: e-commerce sites that store brand metadata on product categories, directory sites that store location data on geographic taxonomies. If your site does, configure each key here the same way you’d configure custom fields.

Media

Settings > Media Translation.

Two configuration toggles for how WPML handles media texts:

Automatically detect best options for translating image texts (alt, caption, title) (recommended). WPML decides per image whether to duplicate the source text or translate it, avoiding both duplicate fields and missed translations.
Translate Media Library texts (alt, caption, title) when translating content. Controls whether media texts are bundled into the post’s translation job in the first place.

For how to translate media (including uploading a different image file per language), see Translating media.

Posts and Pages Synchronization

Settings > Posts and Pages Synchronization.

A different concept from translation: synchronization decides which structural properties of a post propagate from the source to its translations as you edit the source. The mockup lists nine toggles, all on by default:

Page order, page parent, page template.
Comment status, ping status, sticky flag, password, private flag, post format.

When you change the parent of a source-language page, do the translations also get re-parented? When you make the source sticky, do the translations also become sticky? Yes by default. That’s what these toggles control.

Below the sync card sit two delete-cascade options (when deleting a source post or taxonomy, delete its translations too) and two on-create options (copy taxonomy assignments to translations, copy publishing date).

Translated Documents – Publish Behavior

Settings > Translated Documents Options.

A separate concept from synchronization: this controls the publish lifecycle of a translation.

When you receive completed translations. Publish them (when the source is also published) or save as draft.
When you publish the original post. Publish the existing translations or hold them.
Show translated taxonomies in Translation Editor. Off by default; turn on if you want translators to see related taxonomy terms inside the editor instead of managing them separately.

The Per-Post Multilingual Content Setup Meta Box

On the Custom Fields Translation Settings page, a single checkbox at the bottom adds a Multilingual Content Setup meta box to every post edit screen. The box lets editors change a single post’s translation preferences without leaving the editor: change a custom field’s behavior, mark a specific post as not-translatable, etc.

Leave on for editors who manage translation choices at the post level; turn off for sites where editors should never touch translation settings.