How translatable values are extracted

POM Translate turns supported source content into focused translation units when the source object is saved. Extraction decides which text editors can translate and which surrounding markup or technical data must remain controlled by WordPress.

Extraction starts with configuration

A post must use an enabled post type. Within that post type, the site can enable the title, content, excerpt, and supported metadata independently under Settings → POM Translate → Content types.

If body translation is disabled, POM Translate keeps no usable body skeleton for that post type. Enabling only Title does not make the excerpt, body, or every custom field translatable.

Body text becomes meaningful units

The HTML parser recognizes common text containers, including:

• paragraphs and headings;
• list items;
• captions and figure captions;
• buttons and labels;
• table cells and table headings;
• blockquotes, summaries, definitions, and addresses.

Each eligible container can become a translation row while its position remains represented in the content skeleton. Text outside a recognized container can still be collected as a stable loose-text unit when it contains meaningful content.

The interface therefore does not necessarily show one row per Gutenberg block or one row for the complete HTML document. It shows the source units that the parser can safely replace.

Selected attributes are separate strings

Human-facing HTML attributes can require a different translation from visible body copy. POM Translate extracts supported attributes such as:

• alt;
• title;
• aria-label and aria-description;
• placeholder;
• value;
• supported data-* accessibility or label attributes.

They are saved independently and escaped as attributes when restored. A translated paragraph does not automatically translate its image alternative text or form placeholder.

Inline elements remain inside their sentence

Links, emphasis, spans, code, superscript, subscript, marked text, images, and other supported inline elements are not extracted as disconnected words. POM Translate freezes their markup as protected markers inside the containing translation unit.

For example, a sentence with one linked phrase stays one linguistic unit, allowing the translator to change word order while retaining the link structure. The protected markers are explained in How protected markers preserve inline structure.

Shortcodes use supported extraction rules

POM Translate can extract selected shortcode attributes and supported inner text. Shortcode names, structural syntax, IDs, classes, numeric settings, and arbitrary technical attributes are not automatically treated as prose.

Some known shortcode families have dedicated attribute maps, and developers can extend supported parser behavior through the public filters. Always test a representative shortcode after saving it; visual similarity does not prove that its internal attribute names follow a supported contract.

Technical elements are skipped

The standard parser excludes content inside structural or executable elements such as scripts, styles, iframes, embedded objects, audio/video sources, canvases, SVG, pictures, tracks, and templates. Translating their raw contents as ordinary prose could corrupt behavior or duplicate a specialist localization surface.

Custom fields are similarly opt-in. Only supported keys registered as translatable should enter the translation workflow. IDs, serialized layouts, prices, coordinates, API data, and other technical values should remain outside it.

Source changes refresh the set

After a save, POM Translate compares the discovered units with the stored source set:

• unchanged units keep their stable association;
• changed units receive updated source data and require translation review;
• removed units are cleaned from that subject;
• identical normalized source text may reuse an existing non-empty exact-match translation;
• newly discovered target values remain pending until translated.

Autosaves and revisions do not trigger the normal extraction workflow. Programmatic saves, imports, scheduled updates, and command-line changes can do so after WordPress has persisted an eligible object.

Verify what was extracted

1. Enable only the fields required for one post type.
2. Create a post with a heading, paragraph, formatted link, image alternative text, and one supported shortcode.
3. Save the post normally.
4. Open Translations → Translate contents and filter to that post.
5. Confirm visible prose and human-facing attributes appear separately where expected.
6. Confirm classes, IDs, shortcode syntax, and skipped technical elements are absent.
7. Remove one source paragraph, save again, and confirm its obsolete row no longer belongs to the post.

If an expected value is missing, first check the post-type field settings and whether the source object was saved. Do not add technical fields to the translatable allowlist merely to make the table appear more complete.