How to Get a Translated Post ID in WPML: wpml_object_id Explained

A hard-coded post ID can look perfectly harmless—until a visitor switches languages and your “featured” page, related product, or custom taxonomy link quietly points to the wrong content. For developers working with WPML, the real question is not whether an object exists, but whether you can resolve the right object for the current language. That is where wpml get translated post id becomes a practical problem rather than a search query.

WPML provides the standard answer through the wpml_object_id filter, allowing themes and plugins to map an original post, page, taxonomy term, or custom post type ID to its language-specific equivalent. But a reliable implementation depends on details that are easy to miss: object types, missing translations, fallback behavior, and the fact that WPML must be installed and active before its multilingual infrastructure is available.

Once those details click, language-aware IDs stop being a fragile collection of conditionals and become a dependable part of your WordPress code. The difference shows up everywhere—from template queries and navigation links to WooCommerce elements and custom-field integrations.

What Is wpml_object_id and When Should You Use It?

A WordPress ID looks permanent until a site becomes multilingual. In WPML, the English “Contact” page might be ID 42, while its German equivalent is ID 317. They represent the same page to visitors, but WordPress treats them as separate objects. The wpml_object_id filter is the reliable bridge between those IDs.

It maps a source post, page, term, or custom post type object to its translation in the current language or in a language you specify. That makes it the right answer when you need to wpml get translated post id in theme code, a custom query, or a dynamic template. Do not search by title or slug unless you have no alternative: names change, slugs may differ by language, and duplicate titles are common.

Why translated posts have different WordPress IDs

WPML uses a separate WordPress object for each translation. A French product, for example, has its own post ID, metadata, revisions, and permalink; WPML stores the relationship linking it to the English source product. This is why hard-coding an ID is risky. A button pointing to page ID 42 may work in English yet send German visitors back to the English page.

Instead, start with the known source ID and ask WPML for the matching object. The filter follows WPML’s translation relationship rather than trying to infer a match from visible content.

The wpml_object_id filter parameters explained

The filter accepts four practical inputs: the source object ID, its element type, whether to return the original when no translation exists, and an optional target language code. Setting the fallback value to true is useful for shared navigation, where showing the original page is preferable to a broken link. Set it to false when untranslated content should stay hidden.

Omit the language code when the current WPML language should control the result. Pass a code such as de, fr, or es when building a language-specific menu, export, or API response. Explicit targeting prevents a background process from accidentally using the administrator’s current language.

How to choose the correct element type

The element type tells WPML what kind of object the ID represents. For posts and pages, use their registered post-type slugs: post and page. Custom post types work the same way, using their own slug, such as product, event, or portfolio.

• Categories: category
• Tags: post_tag
• Custom taxonomy terms: the registered taxonomy slug, such as product_cat

This distinction matters in related-content blocks and archive templates. A translated category ID is not a translated post ID, even if both happen to be numeric. Use the correct type, then query or link with the returned ID.

How to Get a Translated Post ID in WPML: Practical Code Examples

A multilingual link can fail quietly: the template renders, but visitors land on the wrong language version. The wpml_object_id filter solves that by returning the ID WPML associates with the active or requested language. These copy-ready patterns cover the most common wpml get translated post id tasks.

Get the current-language translation of a page or post

Use true as the third parameter when the original object is an acceptable fallback. If no translation exists, WPML returns the source ID rather than an empty value.

$translated_page_id = apply_filters( ‘wpml_object_id’, 42, ‘page’, true );
$translated_post_id = apply_filters( ‘wpml_object_id’, 125, ‘post’, true );

For example, a shared “Contact” button can use the translated page ID in the current visitor language. The post type argument must match the object: page for pages and post for standard posts.

Get a post ID for a specific language

Add a fourth parameter to request a language explicitly. This is useful when an English template must generate a French CTA, regardless of the current page language.

$french_page_id = apply_filters( ‘wpml_object_id’, 42, ‘page’, true, ‘fr’ );
$french_url = get_permalink( $french_page_id );

Retrieve the translated ID first, then pass it to get_permalink(). Do not assume translated URLs follow a simple string pattern; WPML’s permalink settings may use directories, domains, or query parameters.

Retrieve IDs for custom post types and taxonomy terms

The filter works beyond posts and pages, but the type slug matters. Use the registered custom post type or taxonomy slug, not a display label.

$product_id = apply_filters( ‘wpml_object_id’, 88, ‘product’, false, ‘de’ );
$event_id = apply_filters( ‘wpml_object_id’, 91, ‘event’, false, ‘es’ );
$category_id = apply_filters( ‘wpml_object_id’, 17, ‘product_cat’, false, ‘fr’ );

With false, validate the result before calling get_permalink() or get_term_link(). An untranslated product category should not create a broken navigation URL.

Use a safe fallback when no translation exists

The third parameter controls the behavior: true returns the original ID; false returns no usable translated ID. Neither is universally right. Use true when source-language content is helpful, and false when showing the wrong language would be misleading.

$translated_id = apply_filters( ‘wpml_object_id’, 42, ‘page’, false, ‘fr’ );
if ( $translated_id ) {
  echo get_permalink( $translated_id );
} else {
  echo ‘This page is not available in French.’;
}

In a menu or CTA, you might hide the link instead. For a support article, returning the original page with true is often the more useful fallback.

Common WPML Translated Post ID Problems and How to Fix Them

A translated ID that looks valid can be more dangerous than an empty result. In WPML, a fallback often hides the fact that no translation exists, leaving visitors on the source-language post without an obvious error.

The filter returns the original ID instead of a translation

The usual cause is the return original if missing argument. When it is set to true, wpml_object_id returns the source post ID whenever WPML cannot find a matching translation. That is useful for graceful front-end fallbacks, but misleading during debugging.

To diagnose the issue, set that argument to false. A missing translation should then return an empty value rather than the original ID. If that happens, check that the translated post is connected to the same WPML translation group, has the correct language assigned, and is published. This is the fastest way to confirm whether your wpml get translated post id logic is failing—or WPML simply has no usable target object.

The translated URL is still wrong

Do not try to rewrite language URLs by hand. Resolve the translated object ID first, then pass that ID to get_permalink(). WordPress can then build the canonical permalink, while WPML applies the language URL structure configured for the site.

If the result still points to the wrong language or domain, inspect WPML’s language URL settings: directories, different domains, and query parameters behave differently. Also verify the translation status. An untranslated, draft, or disconnected post cannot produce a reliable translated permalink.

The code works for posts but not custom fields, menus, or WooCommerce data

wpml_object_id resolves relationships between WordPress objects; it does not automatically translate every number stored in the database. A post ID saved in post meta, an option, a menu item, an ACF field, or a WooCommerce related-product field may require separate WPML configuration and an explicit ID conversion when you read it.

For example, a related-product meta field can still contain the original product’s ID even when the current page is French. Configure the field as a translatable or copy-with-translation value where appropriate, then convert the stored ID to the current language before displaying it. Treat each stored relationship as data that needs a language rule, not as something WPML can infer.

A faster translation workflow for sites already using WPML

Teams that already rely on WPML but need lower-cost automated page and post translation can consider LATW AI Translator for WPML. It is an add-on, not a standalone multilingual plugin: an active WPML installation remains required and continues to manage translated IDs, URLs, and site infrastructure. LATW works inside WPML’s workflow and sends content directly from WordPress to your chosen BYOK AI provider, offering a practical alternative to credit-based automated translation costs.

Resolve IDs First, Then Build the Experience

For a dependable way to wpml get translated post id, use wpml_object_id with the correct object type, target language, and a deliberate fallback choice. The important next step is to test the situations that production sites actually encounter: a translation exists, a translation is missing, and fallback is either acceptable or must be prevented. That small amount of testing turns a convenient snippet into predictable multilingual behavior.

Once you have resolved the translated ID, let WordPress generate the permalink, title, thumbnail, or other post data from that ID instead of maintaining language-specific IDs or assembling URLs by hand. In a multilingual site, the ID is not just a database value—it is the reliable connection between the visitor’s language and the content they should see.