Translate your first post

Use one published post to prove source extraction, manual editing, protected formatting, source fallback, and the localized route. Do not begin with a builder-heavy landing page or WooCommerce product.

Prepare a representative source post

Create or choose a normal post containing:

• a title;
• a short excerpt;
• two or three body paragraphs;
• one bold, emphasized, or linked phrase;
• one internal link to another published page.

Write and approve this content in the main language. POM Translate treats the WordPress post as the source object; target-language text does not replace it.

Confirm the post fields are enabled

Open Settings → POM Translate → Content types.

For Posts (post):

1. confirm Enable translations for this post type is selected;
2. leave Title, Content, and Excerpt enabled for this exercise;
3. enable Meta only when a theme or plugin has registered a required prose field as translatable;
4. save the settings.

Posts are enabled by default, but checking the visible controls makes the first test reproducible. Do not add technical custom fields merely to make them appear in the translation table.

Generate the source rows

Open the post in WordPress and select Update.

Saving an eligible post makes POM Translate inspect the selected fields. The body is separated into translatable values while the surrounding structure is retained for reconstruction. Supported inline formatting is represented by protected markers in the translation editor.

In the post editor, the language summary should now show the configured target locale and a count such as:

0% translated (0/N strings)

If it says No translatable strings found yet, confirm that the post is saved, published or otherwise eligible, its post type is enabled, and the selected fields contain text.

Enter the target text

1. In the post’s locale summary, select Manage translations.
2. Confirm Translations → Translate contents opens with the target locale and current post filters.
3. Review the Original Text, Context, and Status columns.
4. Translate each title, excerpt, paragraph, supported attribute, and shortcode text shown for the post.
5. Keep every protected token exactly once and correctly paired.
6. Leave one non-essential value empty for the fallback check.
7. Select Save translations.
8. Confirm WordPress reports Translations updated.

Non-empty manual values are saved with Human status. An empty value remains Pending and renders from the source where the fallback applies.

Handle the slug separately

The target route initially has a locale-specific slug entry derived from the source slug. Translating the post title does not change it.

To use a translated slug:

1. open Translations → Translate URLs;
2. choose the content-URL view;
3. select the post and target language;
4. enter a unique localized slug;
5. save it;
6. use the resulting URL for the visitor test.

Do not change the source post slug solely to obtain a different target-language route.

Inspect the post summary

Return to the source post and reload the editor. The target locale row should now report:

• the translated percentage;
• the translated and total counts;
• Human for manually completed strings;
• Missing for the value deliberately left empty.

If Translate with AI is present, leave it unused for this manual exercise. It requires separate POM AI authorization and would change the status and review path.

Expected result

You should now have:

• one WordPress post, not a target-language duplicate;
• stored target text for the selected locale;
• one deliberate source fallback;
• preserved inline formatting markers;
• a target route ready for a signed-out test.

Continue with Test a translated page as a visitor.