Autor: nagelbieger

Meistens ist es der Spieltrieb, machmal sind es Sachzwänge wie Bug 756116, gelegentlich Testzwecke – immer wieder ist die Versuchung groß, Kalenderpakete von Sunbird und Lightning selbst zu kompilieren – und zwar bitte schön mit deutschsprachiger Oberfläche, dafür machen wir den Übersetzungskram schließlich.

Einer der zahlreichen möglichen Stolpersteine bei diesem Vorhaben sind die unterschiedlichen Übersetzungsgewohnheiten innerhalb des de-Teams. Denn mit den unterschiedlichen Repositories im Rahmen des RapidRelease-Schemas kann für jedes Produkt aus der Mozilla-Familie an unterschiedlichen Stellen mit der Übersetzung angesetzt werden: Kümmert man sich mit l10n-central auch um die früheste Entwicklung? Oder mit dem  Aurora-Kanal um etwas stabilere Entwicklungsergebnisse? Oder mit dem Beta-Kanal um solche, die es nicht mehr weit bis zur Veröffentlichung haben?  Während der vergleichsweise kleine /calendar/-Zweig meist schon für die ‚central-Familie‘ übersetzt ist, wird die meiste andere Übersetzungsarbeit erst auf dem Aurora-Kanal geleistet. Für die letztendlich veröffentlichten stabilen Versionen ist das völlig egal, für die oben erwähnten Kompilier-Verlockungen allerdings nicht: Wenn z.B. die Thunderbird-Übersetzung auf l10n-central nicht komplett ist, kann von diesem Zweig in aller Regel auch kein deutschsprachiges Lightningpaket gebaut werden, weil der Vorgang dann irgendwann mit Fehlern wegen vermisster Dateien oder Einträge abbricht.

Damit genau das nicht passiert, wurde das Werkzeug l10n-merge erstellt und für diverse Build-Setups von Mozilla-Servern aktiviert. Es ist Teil von compare-locales, einem Script, mit dem man v.a. die Vollständigkeit einer Übersetzung prüfen kann. Mit l10n-merge lassen sich dann fehlende Übersetzungsteile durch englische Pendants ersetzen. Das war doch genau das, was ich zum Bauen deutschsprachiger Thunderbird-/Lightningpakete von comm-central/l10n-central gesucht habe!! Leider ist die Verwendung von l10n-merge nicht so richtig gut dokumentiert oder ich habe die wertvollsten Quellen einfach nicht gefunden – jedenfalls ließ sich die Chose nicht sofort fehlerfrei einrichten. Trotz l10n-merge brach das Kompilieren immer noch wegen fehlender Übersetzungsdateien ab!

Der Clou scheint zu sein, dass l10n-merge zwar fehlende Einheiten innerhalb vorhandener Übersetzungsdateien ergänzt, aber keine ganz fehlenden Übersetzungsdateien neu anlegt. Irgendwo habe ich gelesen, dass das ein Feature sein soll, also so gewollt ist. Ich will es aber nicht so, und daher ist mal wieder ein Skript-Gefrickel (merge-central.sh) entstanden, das eine Art Rundumschlag darstellt, aber eben funktioniert:

#!/bin/bash
 
cd comm-central
cp -r comm-central/mozilla/browser/locales/en-US/* de-merge/de/browser
cp -r comm-central/calendar/locales/en-US/* de-merge/de/calendar
cp -r comm-central/chat/locales/en-US/* de-merge/de/chat
cp -r comm-central/mozilla/dom/locales/en-US/* de-merge/de/dom
cp -r comm-central/mozilla/extensions/irc/locales/en-US/* de-merge/de/extensions/irc
cp -r comm-central/mozilla/extensions/venkman/locales/en-US/* de-merge/de/extensions/venkman
cp -r comm-central/mail/locales/en-US/* de-merge/de/mail
cp -r comm-central/mozilla/mobile/locales/en-US/* de-merge/de/mobile
cp -r comm-central/mozilla/netwerk/locales/en-US/* de-merge/de/netwerk
cp -r comm-central/suite/locales/en-US/* de-merge/de/suite
cp -r comm-central/mozilla/toolkit/locales/en-US/* de-merge/de/toolkit
compare-locales -m enxde comm-central/calendar/locales/l10n.ini . de
compare-locales -m enxde comm-central/mail/locales/l10n-central.ini . de
cp -r de/* de-merge/de
cp -r enxde/* de-merge/de

Was passiert hier?

• Erst einmal werden alle englischen Sprachdateien, die für’s Kompilieren eine Rolle spielen könnten, in einen Ordner „de-merge“ kopiert. Damit geht mir später keine Datei mehr als fehlend durch die Lappen!
• Dann wird der Stand der de-Übersetzung mit compare-locales überprüft. Dabei wird auch l10n-merge angewandt, das dafür sorgt, dass um englische Bruchstücke ergänzte Sprachdateien vorübergehend im Ordner „enxde“ abgelegt werden.
• Anschließend werden alle deutschen Sprachdateien nach „de-merge“ kopiert. Entsprechende englische Dateien werden dabei überschrieben. Dateien, die es als de-Variante noch nicht gibt, bleiben in englischer Sprache erhalten.
• Zuguterletzt werden die durch l10n-merge erzeugten Dateien aus „enxde“ ebenfalls nach „de-merge“ kopiert. Manche in „de-merge“ schon vorhandene Dateien werden dabei überschrieben, da sie zwar vollständig ins Deutsche übersetzt, aber eben unvollständig waren. Ersetzt werden sie durch die ‚Hybriddateien‘, die deutschen und englischen Text aufweisen.

Für’s Bauen muss ich dann noch meine .mozconfig ändern, die Übersetzungsdateien liegen nun schließlich nicht mehr klassisch in „de“, sondern in „de-merge“: ac_add_options –with-l10n-base=../de-merge

Tja, lang hat’s gebraucht, um etwas ganz Kleines zu verstehen, nämlich den Schalter „-m“ von compare-locales. Aber immerhin komme ich nun wieder einfach an deutschsprachige Lightningpakete, unabhängig von (ganz legitimen) unterschiedlichen Übersetzungsgewohnheiten.