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 es viel einfacher, wenn bei der Erstellung des Codes bereits an die Übersetzung gedacht wurde, anstatt ihn im Nachhinein dafür zu ändern. 'gettext', 'content' => '/path/to/translation/source-de.mo', 'locale' => 'de' ) ); $translate->addTranslation( array( 'content' => '//my/path/fr-source.mo', 'locale => '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 Basisadapter: 'gettext', 'content' => '/path/to/translation/source-de.mo', 'locale' => 'de' ) ); ]]> 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. Die Verwendung von variablen Werten in einer Übersetzung wird durch die Verwendung von eingebetteten Parametern auch unterstützt. _("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 durch seine Message ID identifiziert. 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 Nachteile: Es ist nicht erkennbar, was der Code ausgeben sollte, wenn 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 keine Ü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, dass 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, wie hier beschrieben, auf seine eigene Weise erstellt, aber es gibt ein paar allgemeine Features, die für alle Adapter relevant sind. Zuerst muß entschieden werden, wo die Übersetzungsdateien zu speichern sind. Bei der Verwendung von Zend_Translate gibt es keinerlei Einschränkungen. Die folgenden Strukturen sind vorzuziehen: Einzeln strukturierte Quellen Positiv: Alle Quelldateien, 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. Auch die Verwendung von mehreren Dateien ist transparent. Anwendungsstrukturierte Quellen Positiv: Alle Quelldateien, für jede Sprache, werden in einem einzelnen Verzeichnis gespeichert. Keine Aufteilung der betreffenden Dateien. Negativ: Die Benutzung von mehreren Dateien für dieselbe Sprache kann problematisch sein. Gettext strukturierte Quellen Positiv: Bestehende Gettext-Quellen können ohne Veränderung der Struktur benutzt werden. Negativ: Die Benutzung von Unterunterverzeichnissen ist für Personen verwirrend, die Gettext noch nie benutzt haben. 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 Quelldateien sind für Zend_Translate am besten benutzbar. Da jetzt bekannt ist, welche Struktur verwendet wird, sollten nun die einzelnen Übersetzungsdateien erstellt werden.