Preserve locale during email generation

An email can be generated outside the request that created its underlying object. Capture the intended locale when the business event occurs and restore it while composing subject, heading, body, links, and attachments.

For custom emails, use pom_translate_with_locale() around the complete rendering operation. Resolve post, term, registered-string, and URL values inside that callback.

WooCommerce orders have a dedicated stored language context managed by POM Translate. Custom order-email integrations should use that order context instead of the current administrator or browser locale.

Do not switch only WordPress gettext locale while leaving POM Translate in another language. Both contexts affect the final message. Likewise, always restore the prior locale so a later recipient is not sent content in the previous customer's language.

Avoid registering recipient-specific or order-specific content as reusable software strings. Dynamic customer data should remain placeholders or escaped runtime values; only stable public template text belongs in translation storage.

Verify two consecutive messages for different locales, including queued delivery. Inspect subject, body, links, date formatting, product names, and fallback text. A preview rendered in the administration screen does not prove that the asynchronous delivery context is correct.