Localize WordPress classification terms

POM Translate overlays language-specific wording on a canonical WordPress term. Counts, assignments, identifiers, and parent relationships remain native WordPress data; translators work only with the presentation layer.

That layer is divided between two administration areas:

• Translations → Translate contents edits the term name and its non-empty description.
• Translations → Translate URLs edits the localized term slug.

Categories and tags are always available for parsing. A custom taxonomy must first be enabled under Settings → POM Translate → Content types.

Run a small acceptance test

1. Pick a classification already visible on a published item.
2. Update it once in its ordinary administration screen to refresh the collected source.
3. In Translate contents, filter All objects to Term and complete one destination locale.
4. In Translate URLs, load the same item and provide its destination slug.
5. Follow a link generated by the site rather than constructing an address manually.
6. Compare the archive, a content card, a breadcrumb, and any faceted control.

Missing term text falls back to the source value. A missing localized slug falls back to the stored source-language slug. Those fallbacks keep the archive reachable but can produce a partially localized result.

Keep three responsibilities distinct

• WordPress owns the taxonomy membership and hierarchy.
• Translate contents owns localized readable copy.
• Translate URLs owns path segments, while language settings decide prefixes.

Diagnose each responsibility separately. A correct heading with a 404 is a routing issue; a valid localized route with source wording is a content-translation issue.

Choose a focused guide