Magento 2 Experten — Hyvä Theme, Tailwind CSS & SEO aus einer Hand ›

Translations for Store Views and the Admin Interface

Translations for Store Views and the Admin Interface

~5 Min. Lesezeit Zuletzt aktualisiert am August 9, 2026

One CSV file per locale is enough - i18n/de_DE.csv covers both the storefront frontend and the admin interface. What differs isn't the file, it's whose locale setting decides which CSV file applies in the first place.

Two completely separate locale sources

On the storefront, the store view determines the locale, via general/locale/code - different store views of the same website can show different languages, as chapter 7 already demonstrates with the website-scoped mironsoft_loyalty/general/enabled. In the admin, each backend user picks their own "Interface Locale" under System > My Account - completely independent of any store view. A German-speaking admin user sees German menu and grid labels even if the shop itself runs entirely in English, and vice versa.

Achtung: Testing admin translations by switching store views on the storefront tests the wrong setting. The interface locale of your own admin account must be explicitly switched to German, otherwise missing admin phrases stay unnoticed - even in an otherwise entirely German-speaking day-to-day workflow.

What gets translated in the admin

  • ACL resource titles from etc/acl.xml ("Loyalty", "Rewards" from chapters 2/18) - Magento's ACL reader automatically wraps every title value in __(), with no explicit call in the XML itself.
  • Menu item labels from etc/adminhtml/menu.xml - same mechanism.
  • <label> elements in UI component XML, such as the reward grid from chapter 16.
  • System/Config field labels from etc/adminhtml/system.xml (chapter 7).
  • Every explicit __() call in an Adminhtml controller or block class, for example a success message after saving a reward.

Scoping the phrase collector to one area

i18n:collect-phrases accepts an --area parameter that only determines which source files get scanned for new phrases - frontend, adminhtml, base, or crontab. The result still lands in the very same single de_DE.csv file; at runtime Magento has no notion of separate CSV files per area, only per locale.

# Scan only adminhtml sources (acl.xml, menu.xml, ui_component, Adminhtml/*):
bin/magento i18n:collect-phrases app/code/Mironsoft/Loyalty \
  --area adminhtml \
  -o app/code/Mironsoft/Loyalty/i18n/de_DE.csv
app/code/Mironsoft/Loyalty/i18n/de_DE.csv
"Loyalty","Treue & Prämien"
"Rewards","Prämien"
"Title","Titel"
"Points Cost","Punkte-Preis"
"Reward saved successfully.","Prämie erfolgreich gespeichert."

Tipp: This project's German PHPDoc comments (CLAUDE.md: "code comments in English") concern only the source code itself, never the __() source strings - those stay English so the CSV file works following exactly the same pattern as in Magento core.

Checklist: configuration and language

  1. Values a merchant should manage themselves belong in system.xml (chapter 7) - not in a custom configuration type (chapter 88).
  2. Ops-/deploy-controlled, database-independent values belong in a custom configuration type, not in system.xml.
  3. Every visible string runs through __(), the source string stays English, the translation lives exclusively in the CSV.
  4. The CSV source string must match the __() call character for character.
  5. Storefront locale comes from the store view, admin locale from the backend user account - two separate settings, one shared CSV file per locale.

Block 11 turns next to this module's test coverage - starting with chapter 91, which takes the PointsCalculator service from chapter 5 as the first target for unit tests.