Übersetzungen für Store-Views und die Admin-Oberfläche

Eine CSV-Datei pro Locale reicht - i18n/de_DE.csv deckt sowohl das Storefront-Frontend als auch die Admin-Oberfläche ab. Was sich unterscheidet, ist nicht die Datei, sondern wessen Locale-Einstellung überhaupt entscheidet, welche CSV-Datei greift.

Zwei vollkommen getrennte Locale-Quellen

Im Storefront bestimmt die Store View die Locale, über general/locale/code - unterschiedliche Store Views derselben Website können unterschiedliche Sprachen zeigen, wie es Kapitel 7 mit dem website-skalierten mironsoft_loyalty/general/enabled bereits vorführt. Im Admin dagegen wählt jeder Backend-Benutzer selbst seine "Interface Locale" unter System > Eigenes Konto - vollkommen unabhängig von jeder Store View. Ein deutschsprachiger Admin-Benutzer sieht deutsche Menü- und Grid-Labels, selbst wenn der Shop selbst ausschließlich auf Englisch läuft, und umgekehrt.

Achtung: Wer die Admin-Übersetzung testet, indem er im Storefront zwischen Store Views wechselt, testet die falsche Einstellung. Die Interface Locale des eigenen Admin-Kontos muss explizit auf Deutsch gestellt werden, sonst bleiben fehlende Admin-Phrasen unbemerkt - selbst in einem sonst rein deutschsprachigen Arbeitsalltag.

Was im Admin übersetzt wird

ACL-Ressourcen-Titel aus etc/acl.xml ("Loyalty", "Rewards" aus Kapitel 2/18) - Magentos ACL-Reader packt jeden title-Wert automatisch in __(), ganz ohne expliziten Aufruf im XML selbst.
Menüpunkt-Labels aus etc/adminhtml/menu.xml - gleicher Mechanismus.
<label>-Elemente in UI-Component-XML, etwa im Reward-Grid aus Kapitel 16.
System/Config-Feld-Labels aus etc/adminhtml/system.xml (Kapitel 7).
Jeder explizite __()-Aufruf in einer Adminhtml-Controller- oder Block-Klasse, zum Beispiel eine Erfolgsmeldung nach dem Speichern einer Prämie.

Den Phrasen-Sammler auf einen Bereich eingrenzen

i18n:collect-phrases akzeptiert einen --area-Parameter, der nur festlegt, welche Quelldateien nach neuen Phrasen durchsucht werden - frontend, adminhtml, base oder crontab. Das Ergebnis landet trotzdem in derselben, einen de_DE.csv-Datei; Magento kennt zur Laufzeit keine getrennten CSV-Dateien pro Bereich, nur pro Locale.

# Nur Adminhtml-Quellen scannen (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: Die deutschen PHPDoc-Kommentare in diesem Projekt (CLAUDE.md: "Code-Kommentare auf Englisch") betreffen ausschließlich den Quellcode selbst, nie die __()-Quellstrings - die bleiben englisch, damit die CSV-Datei nach genau demselben Muster funktioniert wie in Magento-Core.

Checkliste: Konfiguration und Sprache

Werte, die ein Merchant selbst pflegen soll, gehören in system.xml (Kapitel 7) - nicht in einen eigenen Configuration Type (Kapitel 88).
Ops-/Deploy-gesteuerte, DB-unabhängige Werte gehören in einen eigenen Configuration Type, nicht in system.xml.
Jede sichtbare Zeichenkette läuft durch __(), der Quellstring bleibt englisch, die Übersetzung lebt ausschließlich in der CSV.
Der CSV-Quellstring muss zeichengenau zum __()-Aufruf passen.
Storefront-Locale kommt von der Store View, Admin-Locale vom Backend-Benutzerkonto - zwei getrennte Einstellungen, eine gemeinsame CSV-Datei pro Locale.

Block 11 wendet sich als Nächstes der Testabdeckung dieses Moduls zu - beginnend mit Kapitel 91, das den PointsCalculator-Service aus Kapitel 5 als erstes Ziel für Unit Tests nimmt.