TranslationHints 0.2 für Magento veröffentlicht

Ich habe Version 0.2 meiner Magento Extension SSE_TranslationHints veröffentlicht, einem Entwickler-Werkzeug, das die Quelle von Übersetzungen zusammen mit alternativen, überschriebenen Übersetzungen für den selben Text direkt im Frontend anzeigt.

Die Konfiguration ist wie gehabt analog zu den Template Hints:

News

Zusammen mit der Quelle der Übersetzung sieht man jetzt auch alternative Übersetzungen, die von der genutzten Quelle überschrieben wurden und einige zusätzliche Informationen.

Im folgendem Beispiel sieht man den Geltungsbereich (Scope) der Übersetzung (Mage_Customer), die Übersetzung für diesen Scope, sowie die Übersetzung, die im globalen Scope verwendet würde, das heißt wenn es keine Scope-spezifische Übersetzung gäbe. Der CACHED Tag sagt uns, dass die Übersetzungen us dem Translation Cache geladen wurden:

Und hier ist ein Beispiel für eine Übersetzung, die aufgrund des Entwicklermodus nicht angewendet wurde (Es sind mehrere Übersetzungen verfügbar, jedoch keine für den gegebenen Scope Mage_Page):

Vormals wurden Übersetzungen nicht gezählt, wo die Übersetzung gleich dem originalen Text war, da Magento diese vom Translation-Array entfernt. Nun sind sie auch in den Translation Hints sichtar, da es gerade in einigen Eckfällen gut zu wisen ist, bei denen das Verhalten von Magento unerwartet ist.

So sieht es aus, man beachte dass keine Übersetzung gewählt wurde, insbesondere nicht als Scope-spezifische Übersetzung (es ist als ob es keine Übersetzung gäbe):

Um das seltsame Verhalten was ich meinte zu demonstrieren, ändern wir einmal die Übersetzung von “Status” für einen anderen Scope, Mage_XmlConnect und schauen, was passiert:

Nun ist es als ob diese Übersetzung die einzige für “Status” wäre, demnach wird sie global genutzt, sogar wenn der Entwicklermodus an ist. Die Übersetzung für Mage_Sales wurde völlig ignoriert, da die Texte gleich sind. Ja, das ist ein Bug in Magento aber dank der Translation Hints ist das Verhalten transparenter. Ich hätte es ändern können aber wollte keine Unterschiede zum Standardverhalten einführen.

Wer jetzt hinreichend verwirrt darüber ist, wie Übersetzungen und Scopes eigentlich funktionieren, sollte die Zusammenfassung unten unter Präzedenz von Magento Übersetzungen lesen.

Installation

Die empfohlene Installation-Methode ist via Composer, fügt dazu folgendes zu eurer composer.json hinzu:

    "repositories": [
        {
            "type": "git",
            "url": "https://github.com/schmengler/TranslationHints.git"
        }
    ],
    "require": {
        "sse/translationhints": "~0.2.2"
    }

Aber man kann auch nur das Repository herunterladen und app, skin sowie js ins Hauptverzeichnis seiner Magento Installation kopieren.

Präzedenz von Magento Übersetzungen

Übersetzungen werden aus verschiedenenen Quellen zusammengeführt: Modul-Übersetzung aus den jeweiligen XML-Dateien, Theme-Übersetzung aus der translate.csv des aktuellen Themes und Inline-Übersetzungen aus der Datenbank.

Übersetzungen können strikt modulspezifisch sein (gelten nur innerhalb eines Moduls), das ist immer der Fall bei Inline Übersetzungen und optional bei Theme Übersetzungen. Dazu müssen sie in der translate.csv mit Modul-Präfix angelegt werden:

"Mage_Catalog::Add to cart","In die Einkaufstüte legen"

Übersetzungen aus Modulen (z.B. Mage_Catalog.csv) sind nur dann strikt modulspezifisch, wenn der DEVELOPER MODE an ist und es mehrere Übersetzungen für einen Text gibt. Ansonsten gilt die Übersetzung aus dem zuerst geladenen Modul global für alle Module, für die keine eigene Übersetzung des Text definiert ist.

Zusammengefasst sehen die Regeln für die Zusammenführung so aus:

Translation Scope

Für welches Modul die Übersetzung nachgeschlagen wird, hängt vom Modul der Klasse ab, auf der die Methode __() aufgerufen wird:

Es gibt allerdings Möglichkeiten, das Modul für eine Klasse umzudefinieren, was vor allem bei Rewrites von Blocks und Helpers sinnvoll ist. Wie das funktioniert, variiert zwischen Helpers, Blocks und Controllers.

Beispiel für einen Helper:

class IntegerNet_AwesomeModule_Helper_Catalog extends Mage_Catalog_Helper_Data
{
    protected $_moduleName = 'Mage_Catalog';
}

Mehr dazu in meiner Präsentation zum Thema Übersetzungen ab Seite 11.

Um Übersetzungen auch in Unit-Tests immer verfügbar zu haben, ist die explizite Angabe des Scopes sogar notwendig, wie hier auf StackExchange erklärt – bei Mocks schlägt die automatische Zuordnung zum Modul nämlich fehl:

[…] if your helper class is Your_Awesome_Helper_Data, the mocked helper class will actually be Mock_Your_Awesome_Helper_Data. As a module named Mock_Your_Awesome doesn’t exist, nothing can be translated.

Links

• TranslationHints auf GitHub
• Folien “Übersetzungen in Magento”