Polylang Audit Scope: Posts, Pages and Custom Types

Polylang does not automatically treat every WordPress custom post type as translatable—and a translation audit cannot diagnose a post type that Polylang has not enabled. Standard Posts and Pages are normally managed by Polylang, but a custom type such as Case Studies, Products or Events needs its own compatibility and settings checks. When your multilingual audit appears to skip it, start with the post type itself rather than assuming the translations are missing.

This guide establishes the real scope of Polylang and ModelGain Multilingual Abilities, using a reproducible WordPress 7.1 + Polylang 3.9.1 fixture with a public custom post type in both disabled and enabled states. It is a scope and prerequisite guide—not another list of missing translations, a tutorial on running every WordPress Ability, or an automatic translation tool.

The audit scope at a glance

Polylang’s official custom post type configuration guide explains the enablement checkbox. Its public function reference documents pll_is_translated_post_type( $post_type ), the programmatic yes/no check. The plugin also requires the type to appear in WordPress’s get_post_types( array( 'show_ui' => true ) ) result and excludes attachment.

1. Identify the actual post type, not the menu label

A WordPress dashboard menu named “Case Studies” does not guarantee that its registered post type is case-study. The machine-readable identifier might be case_study, portfolio or something else; it must match the exact post_type supplied to the audit. WordPress plugins and themes register CPTs using register_post_type(). Check the code or use a trusted WordPress shell with the site’s documented administrative access.

wp post-type list --fields=name,label,public,show_ui --format=table

Record the name column, not just the label. This command lists WordPress registration flags, not whether Polylang has enabled translation for those types. A publicly accessible archive also does not guarantee that the editor shows a language panel or that a translation relationship is configured. For the underlying API, see WordPress register_post_type() documentation.

2. Check the Polylang setting before running a translation scan

In the WordPress dashboard, navigate to Languages → Settings → Custom post types and Taxonomies. Check whether your custom type appears and whether language/translation management is enabled. Save the reviewed setting and verify the edit screen for one existing item. The checkbox enables Polylang’s handling of that type; it does not create its missing translated posts, automatically assign all languages, or copy editorial content.

Polylang normally lists public custom types for this configuration. A non-public type may require a developer-managed wpml-config.xml or the documented pll_get_post_types filter, and the integration’s consequences should be tested on staging. Its official guide also cautions that custom editor implementations must use standard WordPress actions and filters for language columns and metaboxes to render correctly. If a CPT’s language interface is missing, investigate its editor integration as well as its registration flags—not just whether a checkbox is ticked.

This is a real user-support problem, not a hypothetical SEO keyword: in the WordPress.org discussion “Language panel disappeared from posts, available in pages”, the author reported different language UI behavior between content types; the cause was not established in that thread. A separate Polylang project discussion about non-public CPT translation explains the intentional default visibility boundary and developer filter option. Neither case means that ModelGain can enable types or fix editor interfaces.

3. Verify eligibility using Polylang’s public API

After enabling a CPT, confirm what the current installation actually reports. The following read-only example prints the four relevant facts about a single type in a trusted administrative WP-CLI context. Replace case_study with the name recorded in Step 1; do not run it on the public frontend.

wp eval '
$type = "case_study"; // Replace with the actual post-type name.
$registered = get_post_type_object( $type );
if ( ! $registered ) {
    WP_CLI::error( "Unknown post type" );
}
if ( ! function_exists( "pll_is_translated_post_type" ) ) {
    WP_CLI::error( "Polylang is unavailable" );
}
WP_CLI::log( "type=" . $type );
WP_CLI::log( "public=" . ( $registered->public ? "yes" : "no" ) );
WP_CLI::log( "show_ui=" . ( $registered->show_ui ? "yes" : "no" ) );
WP_CLI::log(
    "polylang_translates=" .
    ( pll_is_translated_post_type( $type ) ? "yes" : "no" )
);
'

For the ModelGain plugin, show_ui=yes and polylang_translates=yes are both necessary. public=yes alone is insufficient; conversely, a developer-enabled private type with show_ui=yes may be eligible if Polylang confirms support. attachment is always excluded from this particular plugin. WordPress 6.9+, Polylang installation, appropriate manage_options permissions and individual edit_post visibility remain separate requirements.

4. What we reproduced with a real custom type

We registered a disposable, public mg_lab_case type with show_ui=true on an isolated WordPress 7.1, PHP 8.3 and Polylang 3.9.1 installation. We first left it disabled in Polylang, then enabled it through Polylang’s actual post-type configuration, and finally disabled it again. We also registered a non-public mg_private_case as a negative control. These names identify test fixtures; they are not WordPress system post types or fields provided by ModelGain.

This test does not prove compatibility with every third-party CPT, editor, WooCommerce integration or Polylang Pro configuration. An individual plugin may use custom capabilities, custom editors or URL rewrites that require separate investigation.

5. Run a bounded audit only after the type passes both gates

Once the type is enabled, ModelGain’s four read-only WordPress Abilities can list configured languages, identify missing links, measure page-scoped coverage and flag supported translation-group anomalies. For a CPT, pass its machine identifier as post_type and choose an explicit source-language slug such as en. For missing-link checks, also provide a target-language slug such as zh.

Each request examines at most 100 source posts. It is not a site-wide translation count. A source page can return zero missing results while has_more=true indicates additional source posts need inspection. Editorial teams must also decide if a particular source item should be translated; missing links are not automatically defects.

The step-by-step commands belong in our existing WordPress Abilities API tutorial. For an overview of absent, draft, inaccessible and invalid translation states, see Polylang missing translations and coverage. To debug a relationship that opens the wrong article, see wrong-language translation links. These are distinct tasks and should not be conflated in a single repair checklist.

6. When the language column or frontend URL still behaves incorrectly

Successful type enablement and an eligible read-only audit do not establish frontend correctness. A custom editor may fail to fire standard WordPress hooks; a theme can have a wrong language-aware query; a permalink or rewrite rule can make a correctly translated CPT return 404. Test one item directly, with its source and target IDs, and compare the editor, public permalink and language switcher separately.

For example, a Polylang issue about adding CPTs via a filter reports an enabled admin interface with a failing frontend archive. In another historical custom-type 404 report, a maintainer asked the reporter to check WordPress rewrite rules. These examples illustrate possible categories of failures, not proof that a current installation shares those causes. ModelGain audits stored post relationships, not editor hook execution, archive rendering, taxonomy translation or HTTP rewrites.

Also distinguish Polylang Pro features from general Polylang/CPT enablement. For instance, translating CPT URL base slugs is documented as a Polylang Pro feature; enabling a free-version CPT for translation is not equivalent to gaining that feature.

7. Select the appropriate next step

Use the smallest set of verified facts: exact post-type name, public and show_ui flags, Polylang enablement, current caller’s permissions, and whether the symptom occurs in the editor, stored relationship or frontend URL. The following decision guide will not change anything on your site.

Only after the scope is verified should you inspect missing translations. If a CPT is not enabled for translation, change its configuration through the owning plugin or Polylang settings after staging review; do not edit raw Polylang database terms to force a result. If the type is enabled but a specific link is absent, decide whether a translation is required and add it using the official editor workflow. If mapping succeeds but routing is wrong, diagnose the relevant theme, CPT plugin or rewrite configuration rather than claiming a translation coverage scanner repaired it.

Product boundaries and a useful review record

ModelGain Multilingual Abilities is a free, permission-gated, read-only diagnostic plugin for WordPress 6.9+ with Polylang. It does not register, enable, translate or repair custom post types; does not audit taxonomy-term translations or attachments; and does not expose a bundled MCP server. External REST discovery is off by default. The plugin’s product page describes its supported actions and limits.

For operational consistency, record the type identifier, Polylang status, language pair, source ID, scan offset/limit, response status, publication state and reviewed editorial decision. That makes a future recheck reproducible without mistaking an invalid type error, skipped page, absent translation or unpublished draft for the same issue.