Send a custom email in the intended language

Custom email work often runs after the original browser request. Store an explicit locale with the business object or queued job instead of detecting it from the later worker.

Register stable template text

Register the subject template, heading, and stable body labels with durable names:

pom_translate_register_string( 'acme.email.subject', 'Your request is ready' );

Keep recipient names, request numbers, private notes, and other dynamic data as escaped runtime placeholders rather than registered strings.

Render under a temporary locale

$message = pom_translate_with_locale(
    $recipient_locale,
    static function () use ( $post_id ): array {
        return array(
            'subject' => pom_translate__( 'Your request is ready' ),
            'title'   => pom_translate_get_post_title( $post_id ),
            'url'     => pom_translate_get_localized_url( get_permalink( $post_id ) ),
        );
    }
);

Build the complete subject, body, links, dates, and attachments inside the callback. It restores POM Translate and WordPress locale state afterward.

Verify delivery

Queue two messages for different locales and process them in one worker. Confirm the second does not inherit the first recipient's translations or date formats. Test missing translations, escaped customer data, localized links, HTML and plain-text variants, and retry behavior.

For WooCommerce transactional email, prefer its stored order locale and managed email workflow rather than duplicating that context system.