Texte gehören zu den Teilen einer Anwendung, die häufig geändert werden. Wenn dann noch externe Übersetzer im Spiel sind, kann es leicht zu fehlenden Übersetzungen kommen

Wir möchten deshalb automatisch testen, dass es zu allen Texten in Sprache A auch Übersetzungen in Sprache B vorhanden sind. Ein solcher Test allein hilft schon sehr, und sollte ja nicht so schwierig sein.

Leider gibt es dabei eine Überraschung: in der Internationalisierung-API findet sich zur Zeit (Rails 2.3.5) keine Möglichkeit, alle Schlüssel aufzuzählen (sprich iterieren). Man muss also offenbar die Yaml-Dateien selbst einlesen, um an die Menge aller definierten Schlüssel zu kommen. Unserer Test wird dabei leider abhängig von der konkreten Art der Datenhaltung.

texts_hash = YAML::load(IO.read('config/locales/de.yml'))

Wie haben nun einen rekursiven Hash. Um alle Schlüssel zu überprüfen, extrahieren wie sie mit einer gesonderten Funktion. Diese Funktion ist einfach rekursiv aufgebaut.

def deep_hash_key(hash, prefix)
  hash.keys.sort.collect{|key2|
    val = hash[key2]
    newprefix = prefix.nil? ? key2 : "#{prefix}.#{key2}"
    if val.is_a? Hash
     deep_hash_key(val, newprefix)
    else
      newprefix
    end
  }
end

Wollen wir jetzt die Übersetzungen für alle Schlüssel prüfen lauert die Zweite Falle: Wenn die Übersetzung eine Variableninterpolation enthält, erhalten wir einen Fehler beim Aufrufen der translate() Methode ohne den passenden Hash. Offenbar liefert uns die API auch keinen Zugriff auf den String ohne Interpolierung. Da uns in diesen Test nur die Existenz einer Übersetzung interessiert, und nicht ihr konkreter Wert, fangen wir die Exception “MissingInterpolationArgument” einfach auf.

Für eine deutsche Anwendung mit Übersetzungen in Englisch und Französisch sieht dann der Test so aus:

def test_all_texts_should_exists
  texts_hash = YAML::load(IO.read('config/locales/de.yml'))
  de_keys = deep_hash_key(texts_hash['de'], nil).flatten
  for lang in ['de', 'fr', 'en']
    I18n::locale = lang
    for key in de_keys
      begin
        val = I18n.translate(key, :default => nil, :raise => true)
      rescue I18n::MissingTranslationData
        val = nil
      rescue I18n::MissingInterpolationArgument
        val = true  # there was a value, only an argument is missing
      end
      assert_not_nil(val, "key missing for locale #{lang}: #{key}")
    end
  end
end

Wenn jetzt eine Übersetzung fehlt, liefert der Test eine Fehlermeldung der Art:

test_all_texts_should_exists(LocalisationTest): key missing for locale en: users.edit.title

Die fehlende Übersetzung können wir dann ergänzen, bevor wir eine neue Version der Anwendung veröffentlichen.

Selbstidentifizierende Fehler

Es gibt in ANSI-C einen Mechanismus, viele Fehler auch ohne Debugger aufzuspüren: Das Assert Macro. Ein Teil des Problems liegt in Deutschland wohl auch im Namen: Assert ist ein Wort, welches im allgemeinen im Englisch an der Schule nicht benutzt wird.

Meine Übersetzung hierfür lautet Zusicherung. Das Assert Macro prüft diese Zusicherung, und druckt, falls es schief geht, seine eigene Datei mit Zeilennummer im Quelltext aus. Ein Beispiel:

int readFile(
    char * filename
    char * buffer
)
{
    int filehandle;
    assert( filename != NULL);
    assert(strlen(filename) > 0);
    assert(strlen(filename) < MAX_FILENAMELEN);
 
    filehandle = open(filename, READ_ONLY);
    ...
}

Falls jetzt irgend jemand meine Funktion mit falschen Parametern aufruft, z.B. mit einem leeren String, passiert während des Programlaufes folgendes:

assertion failed in file readfile.c, line 34:
strlen(filename) > 0
program aborted

Der Tester, wer immer das ist, kann in der angegebenen Datei die Zeile aufspüren, in der der Fehler auftrat, und erfährt dann, dass die Funktion readFile mit einem Leerstring aufgerufen wurde. Oft hat man damit schon die Fehler gefunden, in den anderen Fällen hat man zumindestens einen Anhaltspunkt.

Frage: Sollte man nicht eine wasserdichte Fehlerbehandlung machen?

Welcome to Reality! Die obige Lösung ist ein Einzeiler. In der Praxis bedeutet dieses: Ein assert() schreibt man auch hin, wenn man meint, das ein bestimmter Fall in der Praxis nie und nimmer auftreten wird. Im obigen Beispiel ist der Programmierer der Aufruffunktion dazu verflichtet, der Funktion einen Buffer zur Verfügung zu stellen. Wenn der Buffer bei NULL liegt, hat er Mist gemacht. Bei der Länge des Filenames kommt es auf die Anwendung an: Falls hier ein vom Endbenutzer eingegebener String direkt benutzt wird, ist die assert Lösung allenfalls während der Prototypphase erlaubt.

Die Fehler, von denen man damit rechnet, dass sie während des normalen Betriebes auftreten, sollte man selbstverständlich auch korrekt abfangen.

Das Assert hat auch seinen Sinn, wenn es nicht feuert: Bei einer Fehlersuche kann ich sicher sein, dass ein bestimmtes Problem nicht aufgetreten ist, dass ich den Fehler also woanders suchen muss.

Nicht zuletzt teile ich den armen Leuten, die mein Programm einmal warten müssen, etwas über meine Intention mit: Der Pointer darf kein NULL-Pointer sein, der Dateiname soll weniger als X Buchstaben haben, … Das alles kann man auch in die Kommentare schreiben, aber nur Code lügt nicht.

Frage: In C++ und Java gibt es doch den Exception Mechanismus.

Ja der ist oft noch besser, aber leider auch noch etwas komplizierter. Vieles, was ich gesagt habe, läßt sich auch auf diesen Mechanismus übertragen. Leider kann man sich auch nicht immer aussuchen, in welcher Sprache man programmiert.

Frage: Wenn diese Fehlermeldung dann im laufenden Betrieb beim Kunden auftritt, ist das doch eher peinlich. Und das Programm wird doch bestimmt größer und langsamer? Das heisst doch, nacher muß ich alle asserts() wieder rausnehmen?

Zum Glück nicht! Das Assert läßt sich durch einen Compilerschalter aktivieren oder deaktivieren. Wenn in irgendeiner Headerdatei steht:

#define NDEBUG

oder in der Makedatei:

-DNDEBUG

so wird für das Assert kein Code erzeugt, so als ob man alle assert Zeilen rausediert hätte.

Frage: Wie funktioniert das eigentlich?

Das Geheimnis liegt im Zusammenspiel von Preprocessor und Compiler. Das Assert ist als Macro implementiert, im allgemeinen in der Datei assert.h. Das Grundgerüst ist folgendes:

#ifdef NDEBUG
#define assert(exp)
#else
#define assert(exp) \
 ( (exp) ? (void) 0 : _assert(#exp, __FILE__, __LINE__))
#endif

Das sieht doch reichlich kryptisch aus, ist jedoch gar nicht so kompliziert: Macros sind Textersetzer. Mittels #ifdef…#else…#endif wird dafür gesorgt, das nur Code erzeugt wird, falls das Symbol NDEBUG nicht definiert ist. Dann wird nämlich assert zusammen mit seinen Argument durch einen leeren String ersetzt, der Compiler bekommt die betreffenden Zeilen nicht einmal zu Gesicht. Im Debugfall setzt der Compiler die Wörter __FILE__ und __LINE__ durch die aktuelle Quelldatei (nicht iassert.h, sondern die Datei der Aufrufstelle) und die aktuelle Zeilennummer. Der Ausdruck #exp wird durch den aktuellen Ausdruck als String ersetzt.

Die eigenartige Klammerstruktur (xxx ? yyy : zzz) gehört zum normalen C Sprachumfang, wird jedoch von wohlerzogenen Programmierern nur in Ausnahmefällen wie diesen verwendet. Es ist etwas wie ein verkürztes if-statement. Die Backslashes am Ende der Zeile verlängern die Zeilen, da der Macromechanismus ausschließlich zeilenorientiert arbeitet. Insgesamt erzeugt der Preprozessor aus der Zeile

assert(strlen(filename) < 0);

die Zeile

((strlen(filename) > 0) ? (void) 0 : _assert("strlen(filename > 0", __FILE__, __LINE__));

Die tief im Inneren einer Library definierte Funktion _assert() gibt die Argumente, z.B. mit printf(), auf den Bildschirm aus und bricht das Programm ab.

Frage: Alles schön und gut, aber ich programmiere mit einem Fenstersystem, manchmal programmiere ich auch Anwendungen ganz ohne Bildschirm. Was nun?

Viele Benutzer haben Glück: In einigen Entwicklungsumgebungen gibt es ein assert(), das ein Pop-up-Fenster öffnet. Ansonsten lohnt es sich für solche Fälle, ein assert-Macro selbst zu schreiben. Das prinzipielle Vorgehen ist dabei, eine Ausgabefunktion zu schreiben, die die betreffende Ausgabe irgendwohin ausgibt, die Datei assert.h zu kopieren und statt des _assert die eigene Ausgabefunktion aufzurufen. Die Ausgabe kann in eine Logdatei, über die Soundschnittstelle, als Email, als Fax, oder als was auch immer erfolgen.

Ähnlich ist auch in anderen Programmiersprachen zu verfahren. Meistens bieten die Hersteller irgendeine Entsprechung zu __FILE__ und __LINE__ an, selbst wenn es nicht im offiziellen Sprachstandard ist.

Frage: Das ist ja toll, was man mit Macros alles machen kann, ich habe da gerade eine Idee …

Vorsicht: Wer Macros einsetzt, nur um ein paar Zeilen Code zu sparen, wird es irgendwann bitter bereuen.

Ich habe mal bei einer Firma ein Macro entdeckt, das dazu dienen sollte, Teile eines Records in einen anderen zu kopieren. Dieses Macro war schon mehrere Jahre bei dieser Firma im Einsatz, leider war es nur manchmal korrekt. Ich habe mit mehreren anderen Entwicklern lange vor dem Macro gesessen, um herausfinden, was es eigentlich tat. Es arbeitete ganz gut. Je nach dem, mit welchem Record man es aufrief, überschrieb es jedoch einen verbotenen Speicherbereich. Das Macro war bestimmt für etliche Abstürze verantwortlich, auch bei ausgelieferten Systemen. Die Firma war übrigens kurze Zeit später pleite …

Zurück ins Jahr 2009

Im Jahr 2009 werden Assert-Methoden oft in Unit-Tests verwendet. Dagegen ist auch nichts einzuwenden. Beim vorliegenden Text ging es mir aber um etwas anderes: die Verwendung von Assert im Programmtext selber. Diese Asserts können auch bei unerwarteten Fehler helfen. Sie sind auch allgemeiner: Sie prüfen Aussagen über das Programm, die immer gelten sollen, nicht nur bei bestimmten Testdaten. Asserts im Programmtext selbst sind deshalb auch bei Nutzung von Unittests nützlich.

In der Zwischenzeit ist sind die Netze leistungsfähiger, die Rechner schneller geworden und dank CSS gibt es neue Gestaltungsmittel. Bei der Beschäftigung mit dem JavaScript-Framework “jQuery“  stieß ich auf die animate()-Methode und ich fragte mich: lässt sich das Billboard nicht auch mit JavaScript realisieren?

Die Grundidee ist einfach: Es gibt einen Rahmen und eine Liste von Bildern. Wir manipulieren die “top”-Koordinate der Liste, um die Bewegung zu erzeugen. Die Clipping-Eigenschaft bewirkt, dass wir nur das Innere des Rahmens sehen.

Der HTML-Code besteht somit im wesentlichen aus einer Liste:

< div id="billboard">
<ul>
 <li><a href="link1"><img src="img1" ... ></li>
 <li><a href="link2"><img src="img2" ... ></a></li>
 <li><a href="link3"><img src="img3" ... ></a></li>
 <li><a href="link1"><img src="img1" ...></a></li>
</ul>
</div>

Anders als bei einer Lösung mit Java-Applet (oder auch Flash) haben wir alle Auszeichnungsmöglichkeiten von HTML zur Verfügung. Die Bilder und Links können wir beispielsweise suchmaschinenfreundlich mit title-Attributen versehen. Die Bilder müssen alle die gleiche Größe haben und werden mit Hilfe von css in das Bild eines Rahmens positioniert:

  #billboard{
    width: 260px;
    height:  264px;
    background-image: url(Rahmen.jpg);
    position: relative;
    padding: 0px;
  }
  #billboard ul{
     list-style: none;
     padding: 0px;
     margin: 0px;
     position: absolute;
     top: 30px;
     left: 29px;	
     clip: rect(0px  200px 200px 0px);	
  }
    ...

Verschieben

Eine Methode zum Verschieben ist dank jQuery sehr einfach:

function simple_move_up(){
	$('#billboard ul li').animate({top: '-200px'}, 3000);
}

Etwas komplizierter wird es dadurch, dass wir nach dem letzten Bild nahtlos wieder das erste wieder zeigen wollen. Hier gibt es einen Trick: Für den nahtlosen Übergang wiederholen wir in der HTML-Liste nach den letzten Bild noch einmal das erste. Wenn nun das neue letzte Bild erreicht ist, können wir zum ersten Bild springen, ohne das es bemerkt wird.

var picth = 200;		/* height of a single picture */
var nr_picts = 3;
var curpos = 0;
function move_up(ydiff){
	curpos = curpos - picth;
	if (curpos < (- nr_picts * picth){
		curpos = 0;
		$('#billboard ul li').css({top: curpos});
		curpos = curpos - picth;
	}
 	$('#billboard ul li').animate({top: curpos}, 3000);
}

Endlosschleife

Jetzt bleibt nur noch, unsere move_up Methode in regelmäßigen Abständen aufzurufen.

Dazu setzen wir eine (anonyme) Funktion, die JQuery bei abgeschlossenen Aufbau des Dokumentes aufruft. In dieser rufen wir die Funktion setInterval() aus dem JavaScript-Standard auf.

Bei dem Timing-Parameter müssen wir aufpassen: Der Parameter beschreibt nicht die Zeit zwischen den Animationen, sondern die Gesamtzeit eines Zyklus. Im Beispiel sind dies 8 Sekunden bzw. 8000 Millisekunden, nämlich 3 Sekunden für die Animation und 5 Sekunden Pause.

$(document).ready(function(){
	setInterval("move_up(-200)", 8000);
})

Damit funktioniert das Billboard dank jQuery mit erstaunlich wenigen Codezeilen.

Zur Demoseite mit der rotierenden Reklametafel.

[29dsnh4p5a] Am 23. Juni fand das erste Treffen der Google User Group Hamburg statt. Sie beschäftigt sich mit der Vielzahl der Technologien jenseits einer einfachen Suche, die Google inzwischen zur Nutzung auch für eigene Projekte anbietet.
Die Firma “eprofessional” stellte an diesem Abend den Raum und netterweise auch die Getränke.

Im ersten Teil des Abends stellte Jens Trapp die AppEngine und speziell die Nutzung mit Java vor.
Die AppEngine nutzt nicht eine “normale” relationale Datenbank, sondern die speziellen Datastores von Google zur manchmal über die ganze Erde verteilten Speicherung großer Datenmengen. Um die Anpassung bestehender Software zu vereinfachen, ist für einfache Fälle auch eine Abfrage in SQL-Syntax möglich. Einen ähnlicher Weg ist mir auch von der nativen Symbianentwiclung bekannt. Mich persönlich überzeugt das nicht richtig. SQL ist eine interpretierte Sprache. Wird sie von einer statisch typisierten, compilierten Sprache wie Java oder C++ aufgerufen, verbindet man die Nachteile beider Konzepte, ohne die Vorzüge zu genießen. Man verliert die Typsicherheit, riskiert sogar noch Sicherheitslücken (SQL-Injektion), kann andererseits nicht die wunderbaren Eigenschaften einer kompletten SQL-Implementierung nutzen.

Im zweiten Teil stellte Thomas Steiner “Mapplets” und ihre technologischen Verwandten “Gadgets” vor. Gadgets können per Javascript auch Webservices aufrufen, dabei werden auch die Sicherheitsrichtlinien der Browser beachtet. Die Gadgets können neben der iGoogle-Webseite auch in anderen Kontexten aufgerufen werden und sogar als Suchmaschinenanzeigen geschaltet werden. Als nettes Beispiel wurde eine Anzeige präsentiert, die bei Sonnenschein oder bei Regen jeweils verschiedene Angebote darstellt.

Zum offiziellen Blog der Google Technology User Group Hamburg

[Zu Teil 1]

Oft enthalten Webseiten Sätze, in denen sich ein einzelnes Wort sich dynamisch ändert. Beispielsweise “Sie sind als xxxx eingeloggt.” Zur Übersetzung können wir natürlich den Satz aus seinen Bestandteilen zusammenzubauen. Oft gibt es ein Problem: in verschiedenen Sprachen ist der Satzbau anders.

Besser ist deshalb die sogenannte Interpolation, wie man sie in Ruby ja kennt. Im Satz steht ein markierter Platzhalter, der zur Laufzeit ersetzt wird. Die yaml-Datei zur Spezifikation nutzt hierbei nicht die Ruby Syntax, sondern markiert die zu ersetzenden durch doppelte geschweifte Klammern. Achtung: In Rails 3 hat sich die Syntax leicht geändert.

# Definition
  logmsg: "Sie sind als {{name}} eingeloggt."
# Definition in Rails 3
  logmsg: "Sie sind als %{name} eingeloggt."
 
# Aufruf
I18n.translate(:logmsg, :name => 'Administrator')
# oder in kurz
t :logmsg, :name => 'Administrator'

Wir müssen dabei sicherstellen, das die Parameter von Definition und Aufruf übereinstimmen. Die translate()-Methode dabei relativ tolerant: Überflüssige Parameter werden ignoriert, fehlende Parameter werden mit einem “(???)” ersetzt.

Achtung: die übersetzende Person muss wissen, dass sie die Variablennamen in den Klammern nicht mit übersetzen soll!
Eine weitere kleine Falle lauert bei den Variablennamen: Sie dürfen nicht wie eine der anderen Parameter der translate()-Methode heißen. Verboten sind deshalb “default” und “scope”.

Texte der Validierungen

Selbst wenn wir unsere Applikation nur einsprachig auf deutsch erstellen, gibt es an einer Stelle eine Überraschung: bei den automatisch generierten Fehlermeldungen der Validierungen in den Model-Klassen. Sehr praktisch, aber dummerweise in Englisch. Außerdem setzen sie die Klassennamen und Attributnamen direkt ein. Die Namen der Klassen und Attribute wählen wir normalerweise nach den Bedürfnissen der Programmierer, für die Benutzer sind gelegentlich andere Vokabeln angebrachter.

Der Aufbau einer Fehlermeldung bei einer fehlgeschlagenen Validierung ist im Bild zu sehen:

Zur Anzeige auf Deutsch müssen wir die Texte nur mit den richtigen Schlüsseln in unsere yaml-Übersetzungdatei eintragen. Die Rumpfsätze sind im Bereich (scope) activerecord.messages definiert. Da diese Sätze für alle Anwendungen gleich sind, gibt es schon für viele Sprachen und auch für Deutsch schon Standardübersetzungen.

Übersetzung des Models

Die Namen der Felder und Objekte müssen wir in der yaml-Datei im Bereich activerecord.models.classname beziehungsweise activerecord.attributs.classname.attributname definieren. Dann erkennt sie Rails und setzt sie korrekt in die automatischen Validierungsmeldungen ein.
Die zentrale Übersetzung der Klassennamen und Feldernamen ist auch für die Views interessant. So brauchen wir die Labels von Eingabefeldern nicht ein zweites oder drittes mal übersetzen.

activerecord:
  models:
    term: "Begriff"
  attributes:
    term:
      name: "Name"
      topic: "Sachgebiet"

Das macht für die Views nicht immer Sinn. Die Benutzerschnittstelle sollte sich nicht zu eng an das Model halten. Wichtig ist ja schliesslich der Benutzer.

Validierungen mit eigenen Meldungen

Ein typischer Anwendungsfall für eine eigene Meldung ist die Überprüfung einer Telefonnummer. Die Methoden zur Spezifikation der Validierungen haben einen Parameter “message”. Damit sollte eine Übersetzung ja kein Problem sein: Wir sollten einfach hier die t()-Methode aufrufen können. Leider klappt es so nicht:

# funktioniert so nicht! Does not work!
validates_format_of( :fax,{
    :with => /\A[0-9 \+\-\/\(\)]+\Z/i,
    :message => t('activerecord.errors.messages.bad_phone'),
    :allow_blank => true})

Je nach Version und des verwendeten Deployments startet Rails gar nicht erst hoch oder liefert die gewünschte Übersetzung nicht. Was läuft schief?

Die Sprache ist ja immer pro Request gesetzt. Bei der Definition der deklarativen Valdierungen im Model gibt es noch gar keinen Request! Es macht deshalb keinen Sinn zu diesen Zeitpunkt die translate-Methode aufzurufen.

Aber wie lösen wir das Problem? Typisch für Rails ist die Lösung schon eingebaut. Wenn man sie nicht kennt, kann man sich allerdings lange im Kreis drehen.
Wir können dem message – Parameter nämlich auch ein Symbol statt eines Strings mitgeben: das Symbol wird erst ausgewertet, wenn die Fehlermeldung angezeigt werden soll. Das Symbol wird nacheinander in diesen speziellen Kontexten (scope) ausgewertet:

• activerecord.errors.models.[model_name].attributes.[attribute_name]
• activerecord.errors.models.[model_name]
• activerecord.errors.messages

Unsere Validierung können wir demnach einfach so schreiben:

validates_format_of( :fax,{
    :with => /\A[0-9 \+\-\/\(\)]+\Z/i,
    :message => :bad_phone,
    :allow_blank => true})

Quellen:

Beschreibung (Guide) der Internationalization API:
guides.rubyonrails.org/i18n.html

Sprachdateien für Standardübersetzungen:
github.com/svenfuchs/rails-i18n/tree/master/rails/locale

Zu Teil 3 dieses Artikels

Neulich erhielt ich eine kleine Auftragsanfrage. Ein bestehende Webanwendung wird stark erweitert und dabei auf das CMS “Joomla” umgestellt. Zur Mitgliederverwaltung wird die Erweiterung “Community Builder” eingesetzt.
Bisher hatten die Nutzer eine Nummer als Loginnamen. Diese Nummer soll jetzt für alle alten Nutzer in ein Feld “Mitgliedsnummer” überführt werden. So weit die Anforderung aus Kundensicht.

Analyse

Joomla verwaltet die Benutzer in einer Tabelle jos_user. Der “Community Builder” ermöglicht es, zu einem Nutzerdatensatz weitere Felder hinzuzufügen. Die Felder landen in der gesonderten Tabelle jos_profiler. Mithilfe der ID sind diese beiden Datensätze verknüpft. Auf diese Weise muss der Community Builder keine Tabellen des Joomla-Kerns verändern. Allerdings ist das Hantieren mit zwei Tabellen natürlich programmtechnisch aufwendiger und fehleranfälliger.

Die Anforderung lautet demnach: Für alle jos_user Datensätze, die eine Zahl im Feld username haben, setze diese Zahl in das Feld Mitgliedsnummer des dazugehörigen Datensatzes in der Tabelle jos_profiler.

Geht das mit SQL?

Man kann das Problem sicherlich durch ein kleines PHP-Programm lösen. Wenn es mit einem SQL Befehl funktioniert, ist das viel einfacher. Ein Grund für mich, die Dokumentation zu MySQL genauer durchzusehen.

Auswahl aller Zahlen

Glücklicherweise unterstützt die verwendete MySQL Datenbank reguläre Ausdrucke. Alle usernamen, die nur aus Ziffern bestehen, lassen sich so abrufen:

SELECT username FROM jos_users WHERE username REGEXP '^[0-9]+$'

Verknüpfung beider Tabellen

DieVerknüpfung zweier Datenbanktabellen wird auch als “join” bezeichnet, in unserem Fall ein “inner equijoin”.
Um das Feld username und die Mitgliedsnummer gleichzeitig anzuzeigen, verwenden wir:

SELECT jos_users.username, jos_comprofiler.cb_mitgliedsnummer
FROM jos_comprofiler, jos_users
WHERE jos_comprofiler.user_id = jos_users.id

Diese Anweisung hilft auch bei der Kontrolle, ob am Ende alles richtig gesetzt ist.

Setzen der Daten

Als letzter Schritt bleibt noch, das Feld des einen Datensatzes mit dem Inhalt des Felds des korrespondierenden Datensatzes der anderen Tabelle zu setzen. Zum Glück funktionieren die beiden obigen Techniken auch im UPDATE Befehl von SQL.

UPDATE jos_comprofiler, jos_users
SET jos_comprofiler.cb_mitgliedsnummer = jos_users.username
WHERE jos_comprofiler.user_id = jos_users.id
  AND jos_users.username REGEXP '^[0-9]+$'

Mit einem einzigen SQL-Befehl konnte das Kundenproblem gelöst werden. Möglich macht diese Magie der mathematische Unterbau von SQL, die relationale Algebra.

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: "Unternehmensdaten"
      intro: "Für dieses Unternehmen sind die folgenden Daten gespeichert:"

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.

Zu Teil 2 dieses Artikels