Translate custom post types

POM Translate lists public WordPress post types that provide an administration interface under Settings → POM Translate → Content types. Each eligible type can expose title, content, excerpt, and registered metadata independently.

Enable a custom post type only after confirming which fields its templates actually use.

Configure the post type

1. Open Settings → POM Translate → Content types.
2. locate the row named with its label and slug;
3. enable Enable translations for this post type;
4. enable the relevant Title, Content, Excerpt, and Meta parts;
5. save settings;
6. open one representative object;
7. publish it or make it private;
8. save it to generate source strings.

Core posts and pages are the default translation baseline. A custom type is not assumed to be safe merely because WordPress displays it in this list.

Test field coverage

Use one object containing every supported layout variation. From its editor, select Manage translations and compare rows with:

• the visible single-object template;
• archive cards;
• registered custom fields;
• taxonomy labels;
• builder or shortcode content;
• SEO output.

If a visible value is absent, identify whether it belongs to content, meta, a term, a registered string, or software UI before changing settings.

Respect publication eligibility

By default, only published and private objects create and retain post translation storage. Changing an object to draft, pending, or trash removes its post strings, metadata strings, and content skeleton.

This means a conventional “translate the draft before publishing” workflow is not available on the production object. Use a staging site or private visibility when translations must be prepared before public launch.

Translate the representative object

1. choose one additional locale;
2. translate its title and a small body section;
3. save;
4. configure its localized slug under Translate URLs;
5. open the public or authorized private route;
6. verify the theme retrieves translated title, content, excerpt, and metadata;
7. check the archive and single template.

Only after this passes should editors process the remaining objects.

Account for integrations

A custom post type may depend on:

• custom taxonomies;
• relationship IDs;
• repeated structured metadata;
• shared template objects;
• WooCommerce or another plugin’s runtime context;
• custom REST or AJAX rendering.

Do not translate identifiers or serialized configuration as ordinary text. The owning integration must expose stable text and request the correct locale.

Disable with care

Disabling a post type stops future source parsing and removes its post-editor translation panel. It does not automatically erase every stored translation or repair existing localized links, so plan the change as a content retirement.

Changing only one field part is narrower. While the post type remains enabled, its next eligible save cleans up rows no longer used by that object and continues processing the other enabled parts.

Acceptance checklist

• The post type and exact field parts are enabled.
• The representative object produces expected rows.
• No technical data appears as translatable prose.
• The single and archive templates use localized values.
• The slug and taxonomy terms are handled separately.
• Private or published status matches the editorial plan.
• Source edits regenerate only the intended rows.
• REST, AJAX, and cached output keep the requested locale.

Use the field-focused guides in this chapter when a custom type passes this initial test.