Verbessertes Übersetzungssystem

Stand der Dinge

Der Zustand der deutschen Übersetzung ist zwar gar nicht so übel, aber auch alles andere als perfekt. Das hängt meiner Meinung nach nicht zuletzt daran, das es zu schwer ist, eigene Übersetzungen beizutragen. Es gibt eine Menge verschiedene Translation Packs, die mehr oder weniger als "Geheimtipps" weitergereicht werden. Außerdem ist ein großer Teil der Hilfetexte nicht hilfreich genug und gehörte ebenfalls stark verbessert. Im Grunde gehe ich davon aus, das kein Mensch die Hilfetexte als solche benutzt. Bei vielen Übersetzungen merkt man, das diese aussserhalb Ihres Kontextes übersetzt wurden. Das kann daran liegen, das die ursprüngliche Übersetzung im Launchpad vorgenommen wurde, wo der Kontext eines Begriffes nicht angezeigt wird. Es kann aber auch daran liegen, das es in iDempiere eine Tabelle mit Systemelementen gibt, deren Übersetzungen dann im Bausch und Bogen an vielen einzelnen Stellen eingesetzt werden, obwohl es jeweils einen leicht unterschiedlichen Kontext gibt.

Das hier ist also ein Versuch, es (noch) besser zu machen als http://www.adempiere.com/TranslationProject oder gar http://www.adempiere.com/DE/Verbesserung_deutsche_Lokalisierung. Die aktuellste Seite für deutsche Language Packs im alten ADempiere ist http://www.adempiere.com/German_Language_Pack.

Wie werden bisher Übersetzungen eingepflegt?

• Man kann direkt im Programm Änderungen als SuperUser in die Übersetzungstabellen eingeben
• Man kann Übersetzungen im Launchpad eingeben und korrigieren
• Man kann Übersetzungen im Quelltext eines Translation Packs vornehmen

Und nu?

Wem jetzt direkt der Hut platzt, der kann unter Verbessertes_Übersetzungssystem#Vorläufiger_Arbeitsablauf erst einmal mithelfen. Eine Mail z.B. an User:TBayen reicht, um dabei zu sein.

Welche Eigenschaften wären für ein Übersetzungssystem wunschenswert?

• Man sollte aus der aktuellen Arbeit mit dem Programm heraus (also direkt aus dem Kontext) mit möglichst wenig Aufwand direkt übersetzen können.
• Die Übersetzung sollte im eigenen Programm sofort sichtbar sein (spricht gegen Launchpad).
• Die Übersetzung sollte mit minimalem Aufwand mit einer zentralen Stelle abgeglichen werden können (wie z.B. Launchpad oder eine Art Repository)
• Das Programm sollte mit minimalem Aufwand den aktuellen Stand von der zentralen Stelle erhalten können (z.B. Abgleich täglich oder bei jedem Programmstart)
• Man sollte die verschiedenen kursierenden Translation Packs abgleichen können, um deren Know-How einzubinden
• Abgleiche mit dem zentralen Server sollten schnell gehen, d.h. nur Änderungen umfassen

Bevor man sich entscheidet, wüsste ich gerne noch genauer, wie das mit den Standard Elementen funktioniert.

User:TBayen's Vision

Die folgenden Absätze sind als Fliesstext gehalten, um die Vorstellung zu vermitteln, was uns im Kopf herumgeht. Auf Dauer wird das aber unübersichtlich. Wichtige Schlüsselwörter und Features sind daher fett gedruckt, so das wir im nächsten Schritt eine Liste daraus erstellen können.

Die Oberfläche

Die allermeisten Übersetzungen betreffen Fenster und deren Inhalt. Normalerweise wird dieser Inhalt in seiner Gesamtheit angezeigt, indem man den Hilfe-Button in der Toolbar drückt. Alle Felder des Fensters sind in einem HTML-Dokument erklärt. Nun könnte man beim Drücken dieses Toolbar-Buttons die "Shift"-Taste drücken. Hierdurch wird der Kontext-Hilfeeditor gestartet. Dieser zeigt etwas ähnliches an wie die HTML-Hilfeseite, erlaubt aber, auf einzelne Texte zu klicken, so das man diese in einem Übersetzungs-Editor edieren kann. Dieser zeigt das englische Original und den deutschen Text an. (Vorschlag: Das könnte das ganz normale iDempiere-Fenster für Übersetzungen aufrufen, das ist eigentlich nicht übel, siehe auch Übersetzung_in_iDempiere_anpassen)

Ist man mit dem Übersetzen fertig, wird die Übersetzung in die lokale Datenbank geschrieben. Mit einem einfachen Klick (oder auch immer automatisch) hat man die Möglichkeit, die Änderung auf den Server hochzuladen.

Die Aktualisierung der Übersetzungen vom Server herunter kann z.B. automatisch beim Programmstart erfolgen (vielleicht nur einmal am Tag oder alle paar Tage - das kann man konfigurieren).

Der Server

Alles, was ich oben über eine "zentrale Stelle" geschrieben habe, schreit eigentlich nach einem versionskontrollierten Repository. Ich nige zu Mercurial, weil das auch für den iDempiere Quelltext benutzt wird. Dieses erlaubt, relativ schnell nur einzelne Änderungen auf den Server hoch- oder wieder herunterzuladen. Wir brauchen also ein Format, um die Daten als Verzeichnis zu betrachten. Dazu könnte man beim Abgleich der lokalen Übersetzungen mit dem Repository den bereits vorhandenen XML-Import und -Export benutzen. Dieser ist zwar relativ langsam, stellt aber ein gelerntes und gut verstandenes Format dar.

Über die vorhandene Infrastruktur z.B. von Bitbucket könnte man mehrere Repositories anlegen, um über ein Review-System eine gewisse Sicherheit gegen Dummheit und Vandalismus zu erhalten, wenn man das will. Letztlich können Leute, die sich trauen, einen eigenen Fork machen und diesen dann regelmäßig mit einem zentralen abgleichen oder ähnliches.

Eine Alternative könnte sein, das man einen zentralen Datenbank-Server benutzt und die Versionskontrolle selber implementiert. Damit spart man sich den XML Im- und Export. Dafür ist das aber vielleicht mehr Arbeit, weil man das VCS neu implementieren muss. Wenn man direkt an den Datenbank-Zugriffen ansetzt (im Java-Code oder als Trigger) hätte das den Charme, das man wirklich nur die geänderten Daten überträgt.

Vielleicht gibt es ja schon Leute, die Daten in Datenbanken versioniert haben und erlauben Branches etc. zu verwalten. Weiss jemand was...???

Datenmodell

Nach unserem Treffen am 31.1.2013 haben wir darüber gesprochen, welche Daten in einem Übersetzungsdatensatz stehen sollten:

• iDempiere-Datenbank-ID
• Übersetzungstabelle in der iDempiere-Datenbank
• Benutzer, der ändert
• Datum der Änderung
• Branch-Name
• Status der Änderung: Entwurf/Diskussionsaufforderung/Hilfeaufruf/Abgeschlossen
• Kommentar zur Änderung
• Plugin-Name
• Programmbereich
• Tags (String-Feld), auch für Tickets

Weitere Tabellen/Informationen in der Datenbank:

• Branches können auf anderen Branches basieren (der österreichische auf dem deutschen oder meine private angepasste VErsion auf dem deutschen)
• Arbeitspaket, um Änderungen zusammenzufassen
• Liste von Programmbereichen (ggf. als View)
• Liste von Plugins (ggf. als View)
• Benutzer mit Schreibrechten werden als PostgreSQL-Benutzer angelegt

Kommentare

Ich denke auch, dass der Erfolg der gemeinsamen Übersetzungsbemühungen in weniger davon abhängig sein wird welche existierende Übersetzung als Ausgangspunkt verwendet wird, sondern davon wie effizient sich verschiedene Übersetzungen zusammenführen und später neue Übersetzungen einbringen lassen. Gleichzeitig sollte jeder Übersetzer in der Lage sein mit den Werkzeugen der Wahl zu arbeiten, so wie es am angenehmsten empfunden wird.

Von der grundlegendsten Vorgehensweise würde ich vorschlagen in diesem noch anzulegenden Repository die von iDempiere verwendeten XML Dateien zu verwalten und diese damit auch als Ausgangspunkt für alle weiteren Prozesse zu verwenden. Damit wird jeder klar kommen, denn die Übersetzungen können damit ja -- wie bisher -- direkt in iDempiere gemacht werden. Leute wie ich, die wegen existierenden Übersetzungstools wie z.B. Lokalize aus dem KDE Projekt gerne mit .po Dateien arbeiten, können mit tool4po zwischen XML und .po recht einfach hin- und herkonvertieren.

einen technischen Ablauf mit kurzen Rundlaufzeiten sollte sich prinzipiell realisieren lassen. Aus eigener Erfahrung sollte dabei, rein aus Gründen der Qualitätssicherung, so etwas wie eine Review-Stufe vorgesehen werden in der wesentliche Änderungen geprüft, diskutiert und ggf. verbessert oder sogar abgelehnt werden können.

Dabei kann ich mir vorstellen -- ganz entsprechend der Philosophie moderner verteilter Versionverwaltungssysteme wie Mercurial -- dass die von Dir genannte "automatische Distribution von Übersetzungen im Hintergrund" z.B. auf einen speziellen dafür vorgesehenen Branch laufen. Von dort aus können die Änderungen geprüft und in den Haupt-Branch für die "offizielle iDempiere-Übersetzung" gemerged werden. Im Grunde kann auch jeder Übersetzer einen persönlichen Fork erstellen und damit arbeiten. Letzten Endes ist das egal -- vorausgesetzt wir finden einen praktikablen Weg die Änderungen in einem solchen Fork wieder so einzubringen. Mit praktikabel meine ich, dass man dabei Qualitätssicherung machen kann.

Solche Spezialitäten zu nutzen wie die zwischenzeitliche Umwandlung in *.po Dateien um dadurch bestimmte Tools und Prozesse nutzen zu können lässt sich dann individuell von jedem Übersetzer selbst entscheiden. Wichtig dabei ist, dass der Kernprozess (wie immer der letztlich aussieht) davon unbeeinträchtigt funktioniert.

Was mit im Kontext "Qualitätssicherung" noch einfällt ist das Stichwort "Glossar".

Abgleich verschiedener Versionen mit Lokalize

Wegen des Problems die verschiedenen Versionen abzugleichen könnte [Lokalize] hilfreich sein, weil es dort Funktionalitäten gibt mit denen verschiedene Übersetzungen zusammengeführt werden können. Ich habe das Merging mit Lokalize selbst noch nicht ausprobiert (weil noch nicht gebraucht bislang), aber das sollte exakt zu unserem Anwendungsfall passen.

Praktisch würde das so aussehen:

• Aktuellste Übersetzung aus Mercurial auschecken, mit too4po ins [.po Format] konvertieren und in Lokalize öffnen.
• Neue/andere Übersetzung (wird vmtl. auch als XML vorliegen) auch ins .po Format konvertieren
• Neue Übersetzungen mit der Merge Funktion ("Abgleich") da zusammenführen, wo die neue Übersetzung besser ist
• Ergebnis mit tool4po wieder ins XML-Format konvertieren und nach Mercurial committen

Ich würde diesen Prozess verwenden um die "Übersetzung auf Launchpad" mit meinen Beiträge in die Übersetzung einzubringen die als Ausgangspunkt verwendet wird.

zu erwartende Probleme

• Wie vermeidet man Konflikte bzw. was macht man, wenn das System vollautomatisch arbeiten soll, dann aber ein Merge-Konflikt auftritt?
• Import und Export über ein vollständiges XML-Verzeichnis könnte recht langsam sein. Man müsste das mal messen!

Laut Messungen von Thomas Thiessen dauert der Vorgang "Terminologie Synchronisieren" bei 28 installierten Sprachen bis zu 30 Minuten. Das ist "on the fly" natürlich nicht akzeptabel. :-( Ein Export nach XML dauert ca. 4 Sekunden. Die weitere Verarbeitung könnte dann ein Shellskript im Hintergrund machen. Das wäre also möglich. Die Messung sollte bei den üblichen zwei zusätzlichen Sprachen (Spanisch und lokal) erneut durchgeführt werden. In diesem Fall wird der Vorgang deutlich weniger Zeit benötigen.

• Wir brauchen zusätzlich zur Eingabe-GUI noch ein Tool, um verschiedene Übersetzungen (Branches, wenn man so will) zu vergleichen. (Vorschlag: siehe oben Absatz über [Localize])
• Es gibt Stellen, wo ich gerne Texte einzeln anpassen würde, die in iDempiere zentral über die [Element-Tabelle] verwaltet werden. Dazu müsste man die Einstellung "Centrally Maintained" ausschalten. Kann man das durch die XML-Dateien steuern?
• Eine Frage noch: Wenn alle Beteiligten mit einem aktuellen iDempiere arbeiten, könnte man überlegen, Java-Code als ein OSGi-Bundle einzubinden. Ansonsten müsste die Serveranbindung extern von A/i-Dempiere stehen (also z.B. Datenbank-Trigger benutzen und als eigenes Skript laufen).

Vorläufiger Arbeitsablauf

Die theoretische Diskussion auf dieser Seite ist ja nett, hilft uns im hier und jetzt aber nicht weiter. Da wir aber schnell konkret vorwärtskommen wollen, ist hier der Ablauf beschrieben, wie er mit den augenblicklich verfügbaren Mitteln funktioniert:

• Wir haben die Übersetzung von Evenos zur Basis erklärt.
• Es gibt ein Übersetzungs-Repository auf Bitbucket: https://bitbucket.org/tbayen/translations (NOTE: obsolete link, new repository at https://github.com/bxservice/tbayen.translations)
• Dort kann man die aktuelle Version als *.tar.gz herunterladen oder auch einen Zugang per Mercurial erhalten (Vielleicht dokumentiert der erste, der das macht, wie es genau geht).
• Wer etwas ändert und sicher ist, das es gut ist, lädt es dort per Mercurial hoch. (Wer da Probleme mit hat, kann gerne von mir Hilfe bekommen.)
• Ein Verfahren für das Review haben wir noch nicht definiert. Also bitte sorgfältig arbeiten. (Solange die Anzahl der Leute mit Schreibzugriff noch überschaubar ist, sollte das gehen.) Davon abgesehen, kann man ja auch alle changes wieder entfernen... :-)

Bemerkungen zu diesem Verfahren

kann jetzt jeder arbeiten?

Thomas Thiessen sollte seine Änderungen als XML exportieren können. Ich helfe ihm, das das erste Mal ins Mercurial zu schieben.

Michael forkt das https://bitbucket.org/tbayen/translations Repository. Damit kann er aus den XML-Dateien des Forks *.po-Dateien erzeugen und die dann via Lokalize mit dem Stand der Launchpad-Dateien vergleichen und zusammenführen. Aus dem Ergebnis des Zusammenführung macht er wieder XML daraus, commited das in seinen Fork und erstellt einen Pull-Request für https://bitbucket.org/tbayen/translations. Thomas B. kann die Änderungen dann mergen.

Dieses Vorgehen entspricht im Grunde dem gewünschten Prozess wie auch Änderungen in den iDempiere Hauptzweig eingebracht werden sollten: Pull-Requests erstellen, die dann sehr simpel eingebracht werden können. Falls das insgesamt gut funktioniert, kann man das als Grundlage nehmen für neue potenzielle Übersetzer, die man so in den Gesamtprozess integrieren kann, ohne gleich Commitrechte auf das Hauptrepository zu vergeben. Damit wird das Risiko reduziert mehr oder weniger grosse Aufräumaktionen durchführen zu müssen falls mal ein umfangreicher Betrag aus technischen oder anderen Gründen nicht passt.

release early, release often

http://en.wikipedia.org/wiki/Release_early,_release_often

Soll heissen: Lieber viele kleine Änderungen, die dann sofort von anderen geprüft werden können und ggf. kommentiert werden als wochenlang in sich reinarbeiten und dann einen dicken Monolithen in das Projekt rammen, an dem inzwischen noch andere gearbeitet haben.

Das heisst dann natürlich auch, das man regelmäßig darauf achtet, ob andere Änderungen vorgenommen haben und diese dann zügig einspielt, um Konflikte beim Mergen zu vermeiden. Aber das Problem liegt letztlich in der Natur der Sache und ist nicht zu vermeiden. Ärgerlich ist höchstens, das eine Aktualisierung der iDempiere-Datenbank recht lange dauert (um das z.B. täglich zu machen).

Bitbucket hat übrigens eine wunderschöne Oberfläche, um Änderungen auf Dateiebene zu sehen (z.B. https://bitbucket.org/tbayen/translations/commits/all). Da wir ja als brave Mercurial-Benutzer zu jedem Commit eine intelligente Beschreibung dazugeben, bleibt so immer der Überblick erhalten.