Add POM Translate compatibility to another plugin

Build the integration in a separate custom plugin and use only documented helpers and hooks.

Discover the public surface

1. Identify where the plugin stores base-language public text.
2. Separate post fields, term fields, metadata, settings, shortcode attributes, HTML fragments, URLs, REST/AJAX responses, emails, and background jobs.
3. Exclude IDs, credentials, private data, numbers, enum values, and executable configuration.
4. Determine the save event that can register or extract each source.

Select supported contracts

• Register stable interface text with pom_translate_register_string().
• Add public post metadata with pom_translate_translatable_meta_keys.
• Declare shortcode attributes or parser structures with their parser filters.
• Use explicit post, term, string, and URL helpers for custom output.
• Add narrowly scoped REST/AJAX routes, actions, and textual fields to the public allowlists.
• Carry the locale into queues and emails with pom_translate_with_locale().
• Include locale in integration-owned cache keys and invalidate them from translation lifecycle actions.

Validate failure modes

Test with POM Translate inactive, with only the base locale, with a missing target translation, and with two locale jobs in one process. Confirm source fallback remains usable and no visitor request writes storage or calls machine translation.

Document the minimum compatible version and every field or route the adapter supports. Do not promise generic compatibility with unknown payloads belonging to future versions of the third-party plugin.