matusstafura / magento2-email-translation-checker
Dev CLI tool to render Magento 2 transactional emails per store view, for spotting missing or untranslated content. Not intended for production use.
Package info
github.com/matusstafura/magento2-email-translation-checker
Type:magento2-module
pkg:composer/matusstafura/magento2-email-translation-checker
Requires
- php: >=8.1
- magento/framework: *
- magento/module-customer: *
- magento/module-email: *
- magento/module-newsletter: *
- magento/module-sales: *
- magento/module-store: *
- magento/module-theme: *
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 exposebin/magentoto 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, andcreditmemogroups 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.