Decide what enters the translation workspace

This chapter helps site owners keep POM Translate focused on useful visitor-facing copy. The policy lives at Settings → POM Translate → Content types and is evaluated as WordPress objects are saved.

Begin conservatively. Include the editorial surfaces the site actually publishes, test one representative item, and expand only after the target-language result is correct. This keeps technical values and unused fields out of translators' queues.

Find the right guide

Goal Read
Learn every default, exception, and boundary on the screen Content-selection reference
Add a portfolio, event, product, or another editable object type Enable a post type
Reduce an object's workload to the fields it displays Choose title, content, excerpt, and meta
Include approved text stored outside the main editor Control translatable custom fields
Stop translating an obsolete or internal object type Disable a post type
Localize a custom classification used in archives or filters Enable a taxonomy
Distinguish a term's visible wording from its route Understand taxonomy name and description
Withdraw a custom classification from the workflow Disable a taxonomy
Translate interface messages supplied by code packages Keep software strings separate
Coordinate a production removal with backups and URL checks Retire a translation surface safely

A practical first pass

  1. Map the words visible on one public template to their WordPress source fields.
  2. Activate only the owning content surfaces.
  3. Save the settings, then save the sample source item.
  4. Review what appears under Translations → Translate contents.
  5. Complete one target locale and inspect the public page, archive, navigation, and metadata.

Selection is not retroactive. Older items need a later source save before a newly enabled surface appears. Likewise, turning off an entire type is not a deletion command; retained translation data needs a separate, deliberate maintenance decision.