When a custom post type does not appear in the WPML Translation Dashboard, the problem is often not the content itself but its translation state. A post type registered by a theme or plugin may be set to Not translatable, which keeps it outside the normal multilingual workflow. Custom taxonomies, such as product categories, brands, and regions, are configured separately and require the same kind of decision.
This guide explains how to configure WPML custom post types translation and taxonomy translation from the WordPress admin. You will learn where to check when content is missing, how to choose between translated-only and fallback behavior, and how to test the effect on real entries, archives, filters, navigation, and language-specific views. The objective is not to recommend one mode for every website, but to help you match the setting to your content and language strategy.
What WPML Translation Settings Control
WPML determines whether a post type or taxonomy participates in multilingual workflows through settings available under WPML > Settings. These settings control both eligibility for translation workflows and what visitors may see when a translation is not available. Post types and taxonomies have separate configuration screens, so changing one does not automatically configure the other.
The three available translation states
WPML provides three practical states for custom post types and taxonomies:
- Translatable – only show translated items: the item is available in the target language only when a translation exists.
- Translatable – use translation if available or fallback to default language: the translated item is shown when available; otherwise, the default-language item can be displayed.
- Not translatable: the content does not participate in the normal WPML translation workflow.
The selected state does not mean that every related element is automatically translated. Custom fields, term metadata, slugs, and plugin-generated strings may require separate WPML configuration and review. Treat the translation state as the first decision in the workflow, not as a complete translation setup.
Why a Custom Post Type Is Missing from the Translation Dashboard
The most direct reason a custom post type is absent from the WPML Translation Dashboard is that it is set to Not translatable. In that state, WPML excludes the post type from the Dashboard and does not provide the usual translation controls on the edit screen for its entries.
This situation is common with custom post types registered by themes and plugins. A new content type can therefore appear correctly in WordPress while remaining unavailable for the expected multilingual process. The first troubleshooting action should be to inspect its WPML setting rather than assuming that the content entry is damaged or that the translation service is unavailable.
Start with Post Types Translation
- Open WPML > Settings in the WordPress admin.
- Go to Post Types Translation.
- Locate the relevant custom post type and check whether it is marked Not translatable.
- Choose an appropriate translatable option, save the setting, and test an actual entry.
- Check whether the post type now appears in the Translation Dashboard and whether its edit screen provides the expected translation controls.
If the post type still behaves unexpectedly, review the documentation or compatibility guidance for the theme or plugin that registered it, and consider WPML support where appropriate. Changing the translation state is not a universal fix for every third-party compatibility issue.
How to Configure a Custom Post Type as Translatable
To configure a custom post type, use the WordPress admin rather than beginning with code. Go to WPML > Settings > Post Types Translation, find the relevant type, and select one of the two translatable options. The correct choice depends on whether source-language content may be visible while a translation is still missing.
Choose the post type behavior
Select Translatable – only show translated items when visitors in a target language should see the item only after a translation has been prepared. This is the stricter option. It prevents an untranslated entry from being presented as part of the target-language content, but it can also mean that some content is unavailable until the translation process is complete.
Select Translatable – use translation if available or fallback to default language when retaining access to the item is acceptable even if the target-language version is not ready. With this mode, WPML displays the translation when one exists and uses the default-language item when it does not. The decision should reflect the site’s content and language strategy, not a general assumption that fallback is always better.
Before changing settings on a production site, take a backup and, where possible, test in staging. After saving, verify a representative entry in the Translation Dashboard. Also review whether associated fields, metadata, slugs, and plugin-generated strings behave as intended; enabling the post type alone does not prove that all related content has been configured.
How to Configure Custom Taxonomies
Taxonomies use a separate screen: WPML > Settings > Taxonomy Translation. This separation matters because making a custom post type translatable does not automatically decide how its categories, brands, regions, or other taxonomies should behave. Each taxonomy needs its own translation-state choice.
Configure visible catalog and directory taxonomies
Apply the same three choices to each custom taxonomy: translated-only, translated with fallback, or not translatable. Start by asking how the terms are used publicly. A taxonomy that appears in navigation, product filters, directory listings, archives, or catalog structures usually deserves a deliberate translation review rather than being left in an unexamined state.
- Use translated-only behavior when untranslated terms should not be exposed in the target-language experience.
- Use fallback when the taxonomy should remain available and showing the default-language term is acceptable until its translation exists.
- Use Not translatable only when the taxonomy should remain outside the normal WPML translation workflow.
For product categories, brands, and regions, translate the terms directly when the site depends on consistent multilingual labels. Review the term’s visible name and, where relevant, its description, slug, and term metadata. The selected taxonomy state does not automatically translate these elements or guarantee identical behavior across every WooCommerce, directory, or brand-management plugin.
When to Use Translation Fallback
Fallback is a display behavior for missing translations. When a translation exists, WPML displays the translated post or taxonomy term. When it does not, the default-language item can be displayed instead. This can help preserve access to content, but it also means that visitors may encounter source-language text in a target-language context.
Translated-only versus fallback in practice
Choose fallback for a post type or taxonomy when the website should retain access to the item and the default-language content is acceptable until the translation is ready. This may be a practical pattern for content that must remain discoverable or for a catalog that should not lose an item solely because its localized version is pending.
Choose translated-only behavior when exposing untranslated content would conflict with the site’s editorial, legal, catalog, or language requirements. Neither option is universally correct. After enabling fallback, test language-specific URLs, archives, filters, navigation elements, and the language switcher. Confirm that the resulting experience matches what users should see in each language.
For taxonomies in particular, consider whether a default-language term in a filter or archive would be clear to the target audience. If the answer is no, translated-only behavior may be more suitable for that taxonomy until the required terms are translated.
Ecommerce, Directory, and Agency Site Examples
The same WPML settings can support different content models, so configuration should begin with the user-facing role of each type. Product categories and brands may shape catalog navigation and filtering. Regions may organize directory content or location-oriented listings. Agency-managed custom post types may represent services, case entries, listings, or other public content registered by a theme or plugin.
Review the user-facing role of each content type
For a catalog, identify whether categories and brands appear in menus, archives, product filters, or other visible structures. Decide whether a default-language term is acceptable when its translation is missing. If consistent labels are important, configure the taxonomy as translatable and translate the terms directly rather than relying only on work performed alongside individual posts.
For a directory, review whether regions are used to filter or group entries. A fallback term may keep the structure available, but it can also expose a default-language label. Test the archive and filter experience in each relevant language.
For an agency site, first identify which custom post types are public and which are used only internally. Public types commonly require an explicit review in Post Types Translation. Do not assume that two plugins with similar labels register identical post types or taxonomies. These are configuration patterns, not universal rules for every implementation.
Advanced Compatibility Checks and Testing
If the admin settings do not fully explain the behavior of a custom post type or taxonomy, WPML can also receive translation instructions through wpml-config.xml. Site-specific settings may be added or overridden in WPML’s Custom XML Configuration area. For site owners and agencies, this is best treated as an advanced configuration or compatibility path, not as the starting point for a coding tutorial.
Also remember that the translation state is only one part of multilingual configuration. Custom fields, term metadata, slugs, and plugin-generated strings may need separate attention. WPML settings do not resolve compatibility issues with every third-party product, so unexpected behavior may require guidance from the product vendor or WPML support.
Verification checklist after saving settings
- Confirm that the custom post type or taxonomy is no longer marked Not translatable when translation is required.
- Check the content in the Translation Dashboard and test an actual post or term.
- Review translated and untranslated views in the target language.
- Test taxonomy archives, product or directory filters, navigation elements, and language-specific URLs.
- Check language-switcher behavior and confirm that fallback exposes only content that is acceptable in the target-language experience.
- Review fields, descriptions, slugs, term metadata, and plugin-generated strings separately instead of assuming they were translated automatically.
Keep the installed WPML version in mind when following exact menu labels or preparing screenshots, because the interface and workflow may change. A backup and staging test are sensible safeguards before applying broad changes to production content.
To configure WPML custom post types translation, first check whether the type is set to Not translatable under Post Types Translation. Then choose translated-only or fallback behavior according to the language strategy of the site. Configure product categories, brands, regions, and other taxonomies separately under Taxonomy Translation, and review their visible terms directly.
Finally, test real entries and user-facing structures rather than assuming that one setting covers every field, slug, metadata value, or third-party integration. Fallback can preserve access to untranslated content, while translated-only mode can protect a fully localized experience. The appropriate choice depends on what visitors should see in each language. Explore our WordPress plugins, WooCommerce extensions, themes and membership plans to find the right tools for your website.