Frage zu "svn up" und Ressourcenverteilung ;)

[Burkhard Lück]

Am Montag, 29. Mai 2006 01:51 schrieb Frederik Schwarzer:
> Moin,
>
> da ich gerade an kdegames arbeite, habe ich mir den gesamten Ordner
> mit "svn co ..." gezogen und dann hier eine Datei bearbeitet. Da ich
> gerade die Arbeit an einer weiteren Datei beginnen wollte, habe ich
> vorher "svn up" gemacht, nur um sicher zu gehen. Nun wurden alle
> Dateien meiner Arbeitskopie aktualisiert 'U' und die eine gemergt 'G'.
> Ist das normal?
>
Ja, lies die Ausgabe von:
$svn help up

U  Updated 
Datei auf dem Server geändert, aber nicht deine Arbeitskopie, alles ok
(ich habe vor 2,5 Tagen die Übersetzung für Credits u.a. in kdegames 
vereinheitlicht und vor einem Tag die Änderungen für KTuberling eingespielt, 
Skripty hat dann vor knapp 2 Tagen die Dateien (bis auf KTuberling) noch mal 
mit msgsplit umgebrochen, und die letzte Leerzeile gelöscht -> bekanntes, 
aber noch nicht gelöstes Problem mit unterschiedlicher Arbeitsweise von 
msgsplit lokal und auf dem Server)

G  Merged
Dateien sind sowohl lokal als auch auf dem Server verändert worden, aber an 
verschiedenen Zeilen, die Änderungen konnten daher ohne Konflikt 
zusammengeführt werden, alles ok

C  Conflict
wie G, aber gleiche Zeilen bearbeitet, zusammenführen kann das Programm merge 
von svn die aber nicht, Lösung siehe FAQ 
http://oss.erdfunkstelle.de/kde-i18n/tiki-view_faq.php?faqId=1#q5
Hier wird der Konflikt mit dem Programm msgmerge "gelöst".
Oder mit Editor in utf8 die Datei bearbeiten.

> Andere Frage. Als ich so ein bisschen auf den l10n-Seiten rumgesurft
> bin, fand ich die Doku zu kalarm, die zu 79%+fuzzy fertiggestellt ist,
> aber seit 1191 Tagen nicht mehr angerührt wurde. Ist da jemandem die
> Zeit abhanden gekommen?

Nein, ziemlich sicher nicht. Ich vermute, es gab in einer alten KDE Version 
ein vollständig übersetztes kalarm, dann wurde die englische Dokumentation 
überarbeitet und die neue Vorlage mit der alten deutschen Übersetzung 
zusammengeführt, mit dem von Dir gefundenen Ergebnis. Diese teilweise 
übersetzte Datei wurde aus Zeitmangel noch nicht wieder bearbeitet.
Aber sicher kann das wohl nur Stephan beantworten.

> Da gerade jemand fragte, was noch zu tun wäre; sollten eher fertige
> Dokus korrekturgelesen, oder doch erst halbfertige Dokus
> fertiggestellt werden?
>
Das wurde auf der Liste zu AFAIR noch nicht diskutiert.

Aber ich halte das Korrekturlesen für einen guten Weg zum Einstieg mit wenig 
technischen Hürden, auf dem man nebenbei auch noch viel über Standards, Stil 
usw. lernt. 
Anschließend ist der Einstieg in das Übersetzen leichter. 

Meine Meinung:
Es gibt wichtige Doku (z. B. große Zahl von Nutzern) und weniger wichtige 
Doku. Das ergibt eine wünschenswerte zeitliche Reihenfolge der Bearbeitung.
Da hier aber alle freiwillig mitarbeiten, kann das nur eine Wunschliste sein.

Doku und Übersetzung teile ich vereinfacht in 4 Gruppen ein:
1. "aktuelle" Doku mit Übersetzung
2. "aktuelle" Doku, aber veraltete Übersetzung  (z. B. KSpread)
3. veraltete Doku mit Übersetzung
4. Doku, die noch nie übersetzt war (KDevelop?)

Ich arbeite im Moment in KOffice nur nach dem Prinzip, vorhandene veraltete 
Doku, die unter anderem wegen der umfassenden Änderungen in 1.5 kaum noch 
brauchbar ist, möglichst schnell durch Übersetzungen der aktuellen Doku zu 
ersetzen. Dabei habe ich in KWord nur alle fuzzy und nichtübersetzen 
Nachrichten bearbeitet, dabei auch möglichst Fehler an übersetzen Nachrichten 
beseitigt, mit einem Skript alle Begriffe aus der GUI auf einheitliche 
Übersetzung geprüft und dann eine Version eingespielt, die eigentlich noch 
dringend Korrekturgelesen werden muss, nur damit so schnell wie möglich die 
vorhandene Version mit vielen Fehlern durch eine neue Version mit weniger 
Fehlern ersetzt wird.

Aber das Hauptproblem sehe ich nicht in der Frage, ob erst Korrekturlesen oder 
erst Übersetzen, sondern hier:

Wir übersetzen in stable oft mehr oder weniger veraltete Doku mit mehr oder 
weniger Fehlern, obwohl es in trunk häufig eine bessere Dokuvorlage z. B. mit 
weniger Fehlern gibt.
Einen Teil der Fehler in der Vorlage können wir durch eine "freie" Übersetzung 
korrigieren, und gleichzeitig einen Bugreport über die fehlerhafte Vorlage 
schicken bzw den Fehler selbst in der Vorlage korrigieren.

Das führt aber leider dazu, das beim Übergang auf die nächste Hauptversion (z. 
B. KOffice 1.6) diese schon richtigen Übersetzungen wegen der Änderungen der 
Vorlagen als fuzzy markiert werden und alle nochmal geprüft werden müssen.
Bei KOffice werden das bei der jetzigen Arbeitsweise mehr als 1000 fuzzy sein, 
von denen ein großer Teil aber fälschlicherweise so gekennzeichnet ist. 

Das ist eine unsinnige Verschwendung von Zeit, die wir besser für das 
Korrekturlesen und/oder für neue Übersetzungen verwenden sollten.

Burkhard Lück