-
Notifications
You must be signed in to change notification settings - Fork 6
Wimi Portal Lokalisation
Zur Realisierung der Lokalisation wird das I18n gem verwendet.
Das Wimi-Portal soll von Nutzern in englischer und deutscher Sprache genutzt werden können. Daher müssen alle textuellen Inhalte in beiden Sprachen vorhanden sein. Die verwendete Sprache wird vom Nutzer über sein Profil eingestellt, wobei Englisch der Default ist.
Damit die Beiträge zu diesem Projekt dieser Anforderung entsprechen, wird in den folgenden Abschnitten eine Übersicht über folgende Aspekte gegeben:
- Organisation der Lokalisationsdateien
- Lazy Lookup
- Fehlerbehandlung
- Lokalisation von HTML-Text
- Lokalisation im Kontext eines Models und seiner Attribute
- Lokalisation von Buttons
Dieser Abschnitt deckt die ORganisation der Dateien, sowie ihre interne Struktur ab.
Im Verzeichnis config/locales des Wimi-Portals liegen die Lokalisationsdateien des Projektes im YAML-Format.
Prinzipiell ist eine Aufteilung der Lokalisationen auf beliebige Dateien in diesem Verzeichnis möglich, denn in config/initializers/locale.rb ist folgender Eintrag enthalten: I18n.load_path += Dir[Rails.root.join('lib', 'locale', '*.{rb,yml}')].
Darüber werden alle YAML und RUBY Dateien im locale-Verzeichnis erfasst.
Zur Zeit sind folgende Dateien enthalten:
- de.yml
- de.bootstrap.yml
- devise.de.yml
- validates_timeliness.de.yml
- en.yml
- en.bootstrap.yml
- devise.en.yml
- validates_timeliness.en.yml
Die Dateien en.yml und de.yml beinhalten die Einträge die sich im Kontext von Modelle und deren Attributen befinden. Die Bootstrap Dateien dienen den HTML-Elementen bzw. statischen Texten. Die verbleibenden Dateien (devise und timeliness) werden von den entsprechenden Gems genutzt.
Auf der ersten Ebene der Hierarchie jeder Lokalisationsdatei liegt der Sprachenindex (en bzw. de). Jede weitere Ebene ist in einer Folgezeile und 2 Leerzeichen eingerückt.
Zum Beispiel:
de:
home:
index:
welcome: "wilkommen"
helpers:
application_tabs:
home: "Startseite"
profile: "Profil"
sign_in: "Anmelden"
login: "Anmelden"
logout: "Abmelden"
actions: "Aktionen"
Will man eine Übersetzung addressieren, so kann man ihn aufgrund der Hierarchie eindeutig addressieren. Der folgende Abschnitt zeigt, mit welcher Funktionalität der unter Umständen lange Pfad abgekürzt werden kann.
Eine Funktion mit der in Rails die Lokalisation erleichtert wird, ist der so genannte Lazy Lookup. Durch diese Funktion des Gems ist Rails in der Lage, die passende Übersetzungen den Lokalisationsdateien selbstständig zu finden.
So kann man z.B. schreiben:
<%= t('.welcome') %>
Anstelle des voll ausgeschriebenen Pfades:
<%= t('home.index.welcome') %>
Die Lesbarkeit des Codes wird dadurch Unterstützt.
Was passiert wenn man einen solches Statement in die HTML Datei einträgt, es jedoch vergisst, die Übersetzung in den YAML-Dateien hinzuzufügen?
Unter config/environments liegen die Dateien development.rb und test.rb. Beide Dateien enthalten folgenden Eintrag:
config.action_view.raise_on_missing_translations = true
Dieser Eintrag bewirkt, dass bei fehlender Übersetzung eine Exception geworfen wird. Die Exception wird anstelle der geforderten View angezeigt und enthält neben dem eindeutigen Hinweis, dass eine Übersetzung fehlt, den entsprechenden Pfad in der Lokalisationsdatei, an deren Stelle Rails den korrekten Eintrag erwartet. Man kann den fehlenden Eintrag als oganz einfach an der angegebenen Stelle einfügen.
Eine weitere Folge dieser Zeile ist, dass Test fehlschlagen werden. Jedoch ebenfalls mit eindeutigen Hinweisen darauf, dass eine Übersetzung fehlgeschlagen ist und welche Stelle davon betroffen ist.
Somit soll sichergestellt werden, dass die in den Views angegebenen Übersetzungen auch nicht vergessen werden in die YAML-Dateien einzupflegen.
Wie bereits im Abschnitt zum Lazy Lookup angegeben, soll ein Statement zur Lokalisation in einer View wie folgt aussehen
<%= t('.welcome') %>
und der passende Eintrag in den YAML-Dateien existieren.
Nehmen wir z.B. die Index-View der Projekte. Dort findet sich in der aller ersten Zeile folgender Eintrag:
<%- model_class = Project -%>
Ähnliches findet sich in den _*.form.html.erb wieder:
<%= form_for @project, :html => { :class => "form-horizontal project" } do |f| %>
Über diese Einträge ist es nun möglich direkt auf Attributsnamen der entsprechenden Modellklasse zuzugreifen und übersetzen zu lassen. So z.B. das Attribut Title:
<%= f.label :title, :class => 'control-label' %>
Der zugehörige Eintrag in der de.yml:
de:
activerecord:
attributes:
project:
id: "Id"
title: "Titel"
created_at: "Erstellungsdatum"
users: "Benutzer"
Manchmal ist es jedoch notwendig den vollen Pfad anzugeben, so z.B: bei der Lokalisation der Elemente in derNavigationsleiste:
<%= menu_item t("activerecord.models.project.other"), projects_path %>
In diesem Fall wird sich auf den Namen eines Modells bezogen. In diesem Beispiel wird dabei sogar auf die Mehrzahl verwiesen. I18n bietet auch diese Möglichkeit.
activerecord:
models:
project:
one: "Projekt"
other: "Projekte"
Eine andere Variante die Mehrzahl anzeigen zu lassen ist die folgende:
<%- model_class = Project -%>
<div class="page-header">
<h1><%=t '.title', :default => model_class.model_name.human(:count => 2).titleize %></h1>
</div>
Auch diese Zeile befindet sich in der Index-View des Modells Project.
Zu beachten ist hierbei, dass es sich in diesem Fall nicht um den Titel eines Projektes handelt, sondern um den Titel dieser View. Und das ist Projekte. Das lässt sich daran erkennen, dass auf den Namen der Modelklasse in lesbarerer Form verwiesen wird. Und dann in Pluralform.
Buttons werden genau so behandelt wie andere HTML-Elemente oder Reintext, die übersetzt werden sollen.
<%= link_to t('.cancel', :default => t("helpers.links.cancel")), current_user, class: "btn btn-default" %>
An diesem Beispiel ist der besondere Punkt, dass ein Default mit komplettem Pfad angegeben ist. Sollte also eine Übersetzung fehlen, greift Rails auf den Default zurück (sofern vorhanden, ansonsten Exception).
So ein Default kann auch bei allen anderen Übersetzungen verwendet werden.
So sieht der zugehörige Teil in der YAML-Datei aus:
de:
helpers:
actions: "Aktionen"
links:
back: "Zurück"
cancel: "Abbrechen"
confirm: "Sicher?"
destroy: "Löschen"
new: "Neu"
edit: "Bearbeiten"
Eine Besonderheit bei Buttons findet sich bei Submit-Buttons. In den Formular Dateien befindet sich die bekannte erste Zeile:
<%= form_for @project, :html => { :class => "form-horizontal project" } do |f| %>
Mit dieser weiß Rails in welchem Kontext es sich befindet. darüber hinaus kann Rails feststellen, um welche CRUD-Operation es sich handelt. Dementsprechend sieht der Button wie folgt aus:
<%= f.submit nil, class: 'btn btn-primary' %>
Das nil kann man wie bei jeder anderen Übersetzung ersetzen, muss es jedoch nicht. Man kann es trotzdem mit entsprechenden Einträgen in die YAML-Datei anpassen:
de:
helpers:
submit:
create: "Erstelle %{model}"
update: "Aktualisiere %{model}"
Da Rails weiß, in welchem Modell-Kontext es sich befindet, finden diese Einträge bei allen Modellen anwendung.