README

A Magento 2 CLI tool that renders a transactional email exactly as a given store view would send it — subject, body, and the full HTML — so you can spot missing or untranslated content without waiting for a real customer action to trigger the email.

⚠️ Development tool. Not intended for production use. It renders real order/customer data into terminal output and writes rendered HTML files to var/email-translation-checker/. Don't install this on a production deployment, and don't expose bin/magento to untrusted users.

Why

Magento resolves transactional emails per store view through a chain of config paths, theme fallback, and (for untouched system templates) locale-based {{trans}} CSV translation. There's no built-in way to just see what a given store view actually sends — you either trigger a real email, or dig through Admin > System > Transactional Emails and theme folders by hand. This tool renders it directly, on demand.

Requirements

• Magento 2.4.x
• PHP 8.1+

Install

Via Composer (recommended):

composer require matusstafura/magento2-email-translation-checker --dev
bin/magento module:enable MatusStafura_EmailTranslationChecker
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento cache:flush

Or manually: copy this repo into app/code/MatusStafura/EmailTranslationChecker, then run the same module:enable / setup:upgrade / setup:di:compile / cache:flush steps.

Usage

List all known email codes:

bin/magento email:check-translations --list

Check one email for a store:

bin/magento email:check-translations --store=3 --email=order_new

Prints the resolved subject and a readable plain-text body, and saves the full rendered HTML to var/email-translation-checker/store3_order_new.html.

Use a specific real order as sample data (otherwise the latest order placed in that store is auto-picked):

bin/magento email:check-translations --store=3 --email=order_new --order-id=123456

Force a specific theme, independent of what the store is actually configured to use — handy for A/B-checking theme overrides:

bin/magento email:check-translations --store=3 --email=order_new --theme=Vendor/theme_code

See registered theme paths with:

bin/magento email:check-translations --list-themes

Bypass theme/config resolution entirely and render one exact file — useful once you already know which file you want to check:

bin/magento email:check-translations --store=3 --email=order_new --file=app/design/frontend/Vendor/theme/Magento_Sales/email/order_new.html

Verbose mode (-v) additionally prints the config path, whether the template is a system default or a custom DB template, the full theme fallback chain, the exact resolved file path, and the raw order data used to fill in variables — useful when a value renders blank and you need to know whether it's a translation gap or missing source data:

bin/magento email:check-translations --store=3 --email=order_new -v

How it works

• Resolves the store-scoped config path for the chosen email group (e.g. sales_email/order/template) and determines whether it points at a custom DB template or a system-default template file.
• For system-default templates, renders through Magento's real template filter (Magento\Email\Model\Template), so {{trans}} directives resolve via that store's locale exactly as they would for a real customer — not just raw template markup.
• Builds a variable set matching what Magento's own Order\Email\Sender\* classes provide (order, order_data, billing, formattedBillingAddress, etc.), using a real order (auto-picked or specified via --order-id) so address/variable directives resolve with real data instead of blanks.

Known limitations

• The config paths in the email list are Magento 2.4.7 defaults. A third-party module or older/newer Magento version can shift a path — verify with bin/magento config:show <path> --scope=stores --scope-code=<code> if a code reports "no template resolved."
• Variable sets for order, invoice, shipment, and creditmemo groups are built for their standard templates. A heavily customized template referencing extra variables (check its <!--@vars {...}--> comment block) may render some values blank — that's expected, not a translation bug.
• Newsletter and account emails use placeholder customer data (Test Customer / test@example.com), not a real customer lookup.

License

MIT — see LICENSE.