Professionelle Lokalisierung

[fastjack]

Mich würde mal interessieren, wie folgendes Szenario bei Euch in den Firmen gehandhabt wird:

Die Programmierung verwendet das Java-ResourceBundle. Labels von verschiedenen Sprachen gehen in entsprechende Propertiesdateien und werden entsprechend nach native2ascii kodiert. Das Editieren erfolgt proprietär mit dem ResourceBundle-Editor von Eclipse oder per Hand, mit anschließender Verwendung von native2ascii.
Nun sollen verschiedene Übersetzer extern mit der Übersetzung beschäftigt werden. Das Editieren mit dem ResourceBundle-Editor kann aufgrund fehlender Funktionaliät nicht herhalten (Keine Wissensdatenbank zu den Labels, keine Synonyme etc.), ein Editieren per Hand ist auch nicht zuzumuten. Außerdem sollten die Übersetzer nur die neuen Labels erhalten und nicht immer den ganzen Batzen. Nach der Übersetzung soll ein QM die Korrektheit bestätigen. Die fertigen Übersetzungen sollen wieder automatisch in die Ausgangsdateien integriert werden.

Workflow also: Entwickler erstellt Label -> Übersetzung -> Prüfüng -> Korrekt ? Dann zurück zum Entwickler, ansonsten nochmal Übersetzen -> Abrechnung etc. -> Integrierung

Für Erfahrungen und/oder Vorschläge zu Tools oder Vorgehensweisen wäre ich sehr dankbar.

 

[Wildcard]

Wie wäre es denn mit Eclipse Babel?
Man muss sicherlich ein paar Dinge anpassen um es ausserhalb von Eclipse.org laufen zu lassen, aber das tool dürfte alles können was ihr wollt und steht unter der EPL.
Eclipse Babel Project

 

[kay73]

In unserer Firma (High traffic, etliche Millionen Kunden weltweit) gibt es dafür zwei Systeme: einmal Perl-Legacy mit fiesem Frontend, 10 Jahre Wachstum und keiner kapiert es wirklich. Hintendran MySQL, wobei die Ursprungsversion kein UTF-8 beherrschte und daher krampfige HTML-Hex-Encodings für alles größer 0x80h am Start sind.

Jede Textressource/Textbaustein wird nach außen durch einen "Pfad" in Kombination mit verschiedenen Sprachen, alternativ nach eine Subsidiary ID (Kennung von Tochterfirmen) indexiert und ausgeliefert. Das System beherrscht templating-artige Funktionen: Es stehen Platzhalter verschiedener Art zur Verfügung um Textbausteine in eine Ressource einfliessen zu lassen oder Teile der Ressource anderweitig zu ersetzen.

Der Grund für den Aufwand ist der schiere Umfang des Produktes und sich ständig ändernde Anforderungen. Es ist daher keine Option, für einen Rechtschreibfehler oder eine Anpassung eines Disclaimers das Tomcat-Cluster herunterzufahren... ;-)

An das MySQL- Schema wurde eine Java-Client herangeklemmt, der Texte einigermaßen geschickt abfragt und cached. Da es auf Markt kein Produkt zu geben scheint, das unseren Anforderungen genügt (-eigentlich gibt es gar keins-), war meine Aufgabe, ein neues System zu entwerfen. Es unterscheidet sich aber nicht grundsätzlich von der alten Arbeitsweise. Es ist flexibler bei Sprachen, kann UTF-8 und ist auf Performance optimiert. Die Anforderung eines Textes durchläuft einen mehrstufigen Abbildungs- und Auflösungsprozess und das Resultat wird initial aus der Oracle-DB herangezogen und gecached. Dabei habe ich einen hohen Aufwand getrieben und cache auf Zwischenschritte und Fehlanforderungen, da die Sachen äußerst performancekritisch sind.

Dazu gibt es ein neues Frontend, das zusammen mit den anderen Krempel im Callcenter-Portaltool läuft. Schmankerl ist die Trace-Funktion: Textadministratoren bekommen den kopletten Callstack des Compilerkerns zu sehen und können nachvollziehen, warum eine Textressource so zusammengebaut wurde, wie sie erscheint. Realisiert mit eingewobenem AOP Aspekten.

Wir haben aber auch ein paar Baustellen: Problem ist die Liste der Querverweise eines gegebenen Anzeigeteils aus dem Frontend zu einem Pfad im System und umgekehert; das wird wahrscheinlich manuell redaktionell erstellt werden müssen

Plattformen sind Spring, Hibernate, Oracle und Tomcat.

Der Administrationsprozess ist im Fluss: Bislang wurden Änderungen, Neuanlagen und Importe outgesourcet, jetzt machen wir das selbst. Dabei ist der Prozess noch etwas strittig: Grundsätzlich schreiben Project Manager und -owner feature requirements mit Screenshots und Prozessbeschreibungen wo sich auch Texte und neu zu erstellende Pfade finden. Diese Pfade und die englischen Sprachversionen werden vom Textadministrator initial angelegt und Übersetzungsanforderungen erstellt. Dazu wird eine Exceltabelle (-ja, richtig gelesen...-) durch die Gegend gerschickt und mit Übersetzungen "angereichert". Und wenn es ganz übel kommt, übersetzen die auch brav die Platzhalter. Für den Import das alte Perl-Tool nach Java portiert.

Dann stürzen sich die Testteams auf die neuen Seiten und melden fleissig Bugs. Behoben werden die durch Marketing bzw. durch den Textadministrator, die Entwickler kommen mit dem System kaum in Berührung, müssen allerdings manchmal technischen Support leisten, wenn die Textadministratoren nicht schnallen, wie HTML-Links aufgebaut sind... ;-)