On 15.07.2010 10:37, Andre Schnabel wrote:
Hi,
Nur um das mal richtig zu stellen: selbstverständlich werden immer mal
wieder Dateien verschoben. Das Problem ist das Übersetzungs-Tooling, das
unsinnigerweise die Lage der Strings im Dateisystem für die
Identifizierung benutzt.
Na ja, die Übersetzungen unabhängig von der Lage im Dateisystem vorzunehmen
ist nicht ganz risikolos. Das würde nur funktionieren, wenn Ressourcen
global eindeutige IDs besitzen - stellt das unser Entwicklungsprozess
sicher?
Nein - da müssen wir aber hinkommen.
Des weiteren bin ich auch der festen Überzeugung, dass zu lokalisierende
Inhalte komplett vom Rest der Sourcen zu trennen sind, sowohl was das
Repository als auch was den Build-Prozess betrifft. Die Lokalisierung
von src-Dateien ist also ein Fehler an sich, die Lokalisierung von
xcu-Dateien gerade noch tragbar, weil das Prozessing vergleichsweise
trivial ist.
Eigentlich gehören sämtliche Strings in eigene Dateien, die direkt im
Source Control System eingecheckt werden. Der Build der Language Packs
sollte direkt auf diesen Dateien, ohne weitere persistente
Zwischenformate, aufsetzen und wie gesagt ohne Abhängigkeiten auf andere
Module im Office Code funktionieren (Abhängigkeiten auf Dateien im
"Solver" wären natürlich notwendig und auch OK, sollten aber nach
Möglichkeit minimiert werden).
Wenn man für die eigentliche Übersetzung eine Datenbank verwendet,
sollte diese direkt in das im SCM verwendete Format im - und
exportieren. Das SCM-Format sollte auch möglichst effizient in Bezug auf
diffs sein (was für das sdf-Format so nicht gilt). In Folge dieser
Organisation wäre natürlich für die Lokalisierung im Office noch etwas
Code zu schreiben. Code schreiben können wir aber ganz gut. :-)
Aus eurer Sicht würde ich mal vermuten, dass es auch ein simples
Konvertieren des SCM-Formats in das für das jeweilige Lokalisierungsteam
bevorzugte "Arbeitsformat" geben sollte. Das sollte nämlich auf dem SCM
aufsetzen, nicht auf einer Datenbank als Zwischenmedium.
Ich weiß, jetzt werden sicherlich die Einwände kommen, dass es ja für
viele Übesetzer unzumutbar ist, ein SCM wie Mercurial zu benutzen,
Pootle ist ja sooo viel einfacher. Das mag ich aber gar nicht glauben,
noch dazu wo man für Mercurial notfalls auch GUI Frontends entwickeln
kann (für Windows gibt es schon mindestens eines).
Alles wie immer IMHO.
Wenn dem so ist, wäre es wahrscheinlich einfach, das verwendete tooling
so anzupassen, dass nur noch die IDs (ohne Lage und Name der Quelldatei)
für ein ID-matching benutzt werden.
Voraussichtlich wird es aber länger dauern, diese Tools dann auch in
unserem Prozess zu verwenden, als die eigentliche Änderung vorzunehmen.
Ich denke, dass auch "unser Prozess" genau aus diesem, aber auch aus
anderen Gründen, eine kritische Würdigung verdient. AFAIK gibt es da
auch entsprechende Aktivitäten.
Ciao,
Mathias
--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "[email protected]".
I use it for the OOo lists and only rarely read other mails sent to it.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
