Teil 1 – Übersicht
Software in mehreren Sprachen anzubieten ist eine immer wiederkehrende Aufgabenstellung. Um so erstaunlicher ist es, dass Ruby on Rails erst sehr spät hierfür ein standardisiertes Vorgehen eingeführt hat. Seit Version 2.2. ist eine „Internationalization API“ Bestandteil von Ruby on Rails.
Struktur des Frameworks
Das Framework besteht aus einen „öffentlichen“ und einen „privaten“ Teil. Das I18N Modul bildet den öffentlichen Teil mit den Methoden, die wir in unserem Quelltext aufrufen.
Das private Backend ist austauschbar. Die Standardversion liest die Texte aus Dateien in Yaml-Format oder aus normalen Rubydateien ein.
Aufruf
In unserem Quelltext ersetzen wir alle zu übersetzenden Texte durch Aufrufe der I18N.translate() Methode. Dank eines Alias können wir auch einfach t() schreiben. Als Parameter übergeben wir einen Schlüssel, mit dem das Backend die richtige Übersetzung nachschlägt.
Der Schlüssel kann einen String oder ein Symbol sein. Normalerweise ist ein Symbol als Hashkey ja geringfügig performanter. Da der Schlüssel bei der Verarbeitung in seine Bestandteile zerlegt wird, erwarte ich, dass dieser Vorteil verschwindet.
In einer typischen Webapplikation sind viele der zu übersetzenden Texte in den Views, also den .erb-Templates. Als Abkürzung für reinen HTML-Text gibt es folgenden Tag:
<%=t 'key' %>
Organisation
Die Symbole haben eine hierarchische Struktur. Als Organisation bietet sich an:
„controllername.viewname.key“, also zum Beispiel ‚companies.show.header‘
Die Sprachdateien
Als Formate der Sprachdatei sind Ruby-Quelltext und Yaml vorgesehen. Die Übersetzung wird nun meistens von einer Person ohne Rubykenntnisse durchgeführt. Deshalb ist die Yaml-Datei zu empfehlen.
Das Format sieht so aus
de: users: show: header: "Company Data" intro: "For this company, we have stored the following data:" |
Die Sprache ist der erste Key, normalerweise sind dadurch die Texte der verschiedenen Sprachen räumlich getrennt. Um die Arbeit für die Übersetzer zu erleichtern, können mit einem ‚#‘ Zeichen Kommentare eingefügt werden. Und natürlich sollten die bezeichnenden Schlüsselwerte möglichst klar sein. Aber selbst dann sind die YAML-Dateien nicht optimal, wenn Entwickler und Übersetzer nicht dieselbe Person ist.
Hello Meier! If you need to localize your Rail app into multiple languages, there are some alternative tools, but I suggest to go for POEditor software localization management platform; the work interface is neat and simple to handle. The tool doesn’t support .yaml files now, but , you can convert them to po formats using this free converter tool http://yml2po.com/. It worked for me, maybe it can help you too.