Follow the public compatibility contract

Supported integrations use documented procedural helpers, shortcodes, merge tags, and pom_translate_* WordPress hooks. Internal classes, tables, options, cache keys, AJAX handlers, and private service details are implementation, even when discoverable in the plugin files.

Defensive integration

• Check function_exists() before calling a helper.
• Register filters on normal WordPress initialization, not by editing POM Translate.
• Accept the documented arguments and return the documented type.
• Preserve unknown array keys for forward compatibility.
• Validate locale codes against configured languages.
• Escape at the final output boundary.
• Avoid writes during public render requests.

Do not assume a missing translation returns an error. Most public value helpers deliberately fall back to source content.

Version and failure behavior

Your component should keep working in the base language when POM Translate is inactive. Remove only your own callbacks on deactivation and do not delete shared translation records.

When a hook changes routing, parsing, or cached output, test activation order and priority explicitly. Do not depend on another callback's undocumented priority.

Document the minimum POM Translate version your integration requires and manually verify it on supported WordPress, PHP, multisite, REST/AJAX, and WooCommerce combinations relevant to the component.