Der nächste Schritt ist die Benutzung des Adapters im eigenen Code. Das obige Beispiel zeigt eine Ausgabe ohne Unterstützung für Übersetzungen. Der Code wird üblicherweise in der eigenen Muttersprache geschrieben. Üblicherweise muß nicht nur die Ausgabe übersetzt werden, sondern auch Fehler- und Logmeldungen. Der nächste Schritt ist also die Integration von Zend_Translate in den eigenen Code. Natürlich ist das viel einfacher wenn der Code bereits so geschrieben wird das er übersetzbar ist, anstatt Ihn im Nachhinein dafür zu ändern. addTranslation('//my/path/fr-source.mo', 'fr'); print $translate->_("Beispiel") . "\n"; print "========\n"; print $translate->_("Hier steht Zeile eins") . "\n"; printf($translate->_("Heute ist der %1\$s") . "\n", date('d.m.Y')); print "\n"; $translate->setLocale('fr'); print $translate->_("Hier ist Zeile zwei") . "\n"; ]]> Jetzt schauen wir uns genauer an, was getan wurde, und wie Zend_Translate in den eigenen Code integriert wird. Erstelle ein neues Zend_Translate Objekt und definiere den Basis Adapter: In diesem Beispiel haben wir den Gettext Adapter ausgewählt. Die Übersetzungsdatei source-de.mo wird im Verzeichnis /path/to/translation platziert. Diese Gettext Datei beinhaltet eine deutsche Übersetzung und es steht auch eine zweite Sprachquelle für Französisch zur Verfügung. Der nächste Schritt besteht darin alle Strings zu ummanteln die übersetzt werden sollen. Die einfachste Möglichkeit besteht wenn nur einfache Strings oder Sätze vorhanden sind wie zum Beispiel: _("Beispiel") . "\n"; print "========\n"; print $translate->_("Hier ist die Zeile Eins") . "\n"; ]]> Einige Strings müssen nicht übersetzt werden. Die Trennlinie wird immer eine Trennlinie sein, auch in den anderen Sprachen. Variable Werte in eine Übersetzung zu integrieren wird aber auch unterstützt durch die Verwendung von eingebetteten Parametern. _("Today is the %1\$s") . "\n", date("d.m.Y")); ]]> Statt print() wird die printf() Funktion benutzt und alle variablen Parameter mit %1\$s Blöcken ersetzt. Der erste ist %1\$s, der zweite ist %2\$s, und so weiter. Auf diesen Weg kann übersetzt werden ohne den exakten Wert zu wissen. In unserem Beispiel ist das Datum immer der aktuelle Tag, aber der String kann übersetzt werden ohne über den aktuellen Tag bescheid zu wissen. Jeder String wird im Übersetzungsspeicher identifiziert durch seine Message ID. Man könnte diese Message IDs statt des Strings im Code wie folgt verwenden: _(1) . "\n"; print "=======\n"; print $translate->_(2) . "\n"; ]]> Allerdings hat dies mehrere grobe Nachteile: Es ist nicht erkennbar was der Code ausgeben sollte indem man ihn betrachtet. Es werden auch Probleme auftreten wenn einige Strings nicht übersetzt worden sind. Man muß sich immer vor Augen halten wie Übersetzungen funktionieren. Zuerst prüft Zend_Translate ob in der gesetzten Sprache, für die angegebene Message ID oder den String, eine Übersetzung vorhanden ist. Wenn kein Übersetzung gefunden wurde, wird in der nächsten tiefer gelegenen Sprache gesucht wie in Zend_Locale definiert. "de_AT" wird also zu "de". Wenn auch hier keine Übersetzung in der Sprache "de" gefunden wurde, wird der Original String zurück gegeben. Das bedeutet also das immer eine Ausgabe existiert, selbst wenn für eine Message ID keine Übersetzung in der Quelle vorhanden ist. Zend_Translate wird niemals eine Exception oder einen Fehler ausgeben wenn ein String übersetzt werden soll. Der nächste Schritt besteht in der Erstellung der Übersetzungsdateien für die verschiedenen Sprachen welche übersetzt werden sollen. Jeder Adapter wird auf seine eigene Weise, wie hier beschrieben, erstellt aber es gibt ein paar generelle Features die für alle Adapter relevant sind. Zuerst muß entschieden werden wo die Übersetzung Dateien zu speichern sind. Bei der Verwendung von Zend_Translate gibt es keinerlei Einschränkungen. Aber die folgenden Strukturen bevorzugt verwendet werden: Einzeln strukturierte Quellen Positiv: Alle Quell Dateien, für jede Sprache, werden in einem einzelnen Verzeichnis gespeichert. Keine Aufteilung der betreffenden Dateien. Sprachlich stukturierte Quellen Positiv: Jede Sprache wird in Ihrem eigenen Verzeichnis gespeichert. Einfache Übersetzung, da jedes Übersetzungsteam nur ein einzelnes Verzeichnis zu übersetzen hat. Und die Verwendung Verwendung von mehreren Dateien genauso transparent. Applikations strukturierte Quellen Positiv: Alle Quelldateien, für jede Sprache, werden in einem einzelnen Verzeichnis gespeichert. Keine Aufteilung der betreffenden Dateien. Negativ: Die Benutzung von mehreren Datein für die selbe Sprache kann problematisch sein. Gettext strukturierte Quellen Positiv: Bestehende Gettext Quellen können, ohne Veränderung der Struktur, benutzt werden. Negativ: Die Benutzung von Sub-Sub Verzeichnissen ist für Personen, die Gettext noch nie benutzt haben, verwirrend. Datei strukturierte Quellen Positiv: Übersetzungsdateien sind in der Nähe Ihrer Quelle zu finden. Negativ: Zu viele und auch kleine Übersetzungsdateien führen zu einer schwierigen und langwierigen Übersetzung. Es muß auch jede Datei als Übersetzungsquelle hinzugefügt werden. Einzeln strukturierte und sprachlich strukturierte Quell Dateien sind für Zend_Translate am besten benutzbar. Also jetzt, da bekannt ist welche Struktur verwendet wird, müssen die einzelnen Übersetzungs Dateien erstellt werden.