Hallo Liste,
Hallo Rhonda,
erst mal vielen Dank, dass Du so beharlich dieses Thema anschiebst.
Wir diskutieren hier Übersetzungen von Debconf-Vorlagen,
Handbuchseiten, Webseiten, ... die u.U. nur ein kleiner Teil der
deutschsprachigen Benutzer sehen wird, und führen darüber z.T.
aufwändige Korrekturzyklen aus (die selbst bei erfahrenen Übersetzern
oft immer wieder Verbesserungen bringen) und bei einem so sichtbaren
Projekt fehlt nahezu jegliche QS. Das wirft einen sehr schlechten
Eindruck auf die deutsche Übersetzung und ev. findet dann ein LANG=C
den Weg auf Systeme, die von unseren anderen Übersetzungen durchaus
profitieren könnten (und würden).
Ich habe selbst eine Reihe von Paketbeschreibungen »auf der Liste«
die ich noch korrigieren möchte.
Ich unterstütze daher den Vorschlag, erst mal die Reißleine für die
übersetzten Paketbeschreibungen zu ziehen und sie nicht mehr
anzuzeigen.
Gleichzeitig unterstütze ich den Vorschlag, einen geordneten
Begutachtungszyklus zu unterstützen, und damit möglichst zügig die
Übersetzungen wieder aktivieren zu können (nach der geordneten, selbst
QS-fähigen QS!). Wenn ich das richtig sehe, sind wir ja nicht so
stringent an die Lenny-Veröffentlichung gekoppelt, da die
Paketbeschreibungen ja per apt oder p.d.o auch nach der
Veröffentlichung »ins Haus kommen« könnten.
On Tue, May 20, 2008 at 03:24:09PM +0200, Jens Seidel wrote:
> On Tue, May 20, 2008 at 10:27:23AM +0200, Gerfried Fuchs wrote:
> > Am Dienstag, den 20.05.2008, 09:22 +0200 schrieb Thomas Weber:
> > > Die einzige Alternative, die ich sehe: Einfuehren einer Zwischenschicht:
> > > Alle Uebersetzungen (egal von wem) kommen da rein und erst wenn
> > > _bestimmte_ Leute die akzeptieren, geht es weiter.
Ja!
Dies unterstütze ich stark. So wie bspw. auf die Webseite nur
bestimmte Personen schreibend zugreifen dürfen (und die Übersetzungen
landen ja auf p.d.o, WWW-sichtbar).
> Mhm, ja, das wäre denkbar. Ich hatte mal eine Zeit lang täglich die
> Translation-de-Dateien heruntergeladen und die Diffs angesehen sowie
> korrigiert. Es war eigentlich gar nicht mal so viel, da immmer ein
> paar Übersetzungen mehr rausgeflogen sind (veraltet) als neue
> hinzukamen.
Noch einen Grund, jetzt die Reißleine zu ziehen und erst mal ein gutes
System aufzusetzen, wenn Du diese QS *nicht* mehr durchführst /
durchführen kannst (ich nahm an, dass das noch liefe!).
> Da Translation-de eine einfache Textdatei ist und die
> Paketbeschreibungen darin nicht immer untereinander verschoben werden
> (auch wenn sie wohl nicht alphabetisch sortiert sind), kann man eine
> eigene Versionsverwaltung drüber legen.
Super! Das erleichtert das System sehr.
> Ich bin sicher, dass das DDTP-Team keine Probleme hätte, solche manuell
> erstellten Dateien statt der bisherigen auf die FTP-Server zu
> verschieben. Technisch also ein Kinderspiel.
Kannst Du das herausfinden?
> Schwebt irgendjemand etwas an Details vor? Welches VCS? git? (Kenne nur
> Subversion und CVS gut, wäre aber für git). Was einpflegen, die
> komplette Translation-de-Datei oder immer nur eine einzelne Beschreibung
> pro Datei (kommt git damit klar?)?
Die derzeitigen Schnittstellen sind auch aus meiner Sicht sehr
ineffizient. Ich denke, wir sollten über Alioth ein Projekt aufsetzen
(ähnlich DWN trans). Git wäre mir recht, aber auch SVN, ansonsten
kenne ich noch CVS. Aber letztendlich sind das Werkzeuge, wir sollte
hier erst mal den Prozess klarstellen und dann das RCS bestimmen.
> > > Mir schwebt dabei was in der Art von gits "Signed-off by" vor: sprich
> > > wenn jemand die Uebersetzung gut findet, nimmt er sie in sein Repo auf.
> > > Haben zwei oder drei Leute das gemacht, geht es automatisch weiter.
>
> Ja, klingt gut, auch wenn ich nur ein manuelles "Signed-off by"
> (Mailinglisten, Subversion, ...) kenne.
Mir gefällt das, aber es muss maschinenlesbar sein. Denkbar wäre
folgender Ablauf:
1.Nicht vertrauenswürdige Quelle
|
v
2.Regelmäßiges Syncen in DDTP-RCS
|
v
3.Ein "zugelassener" Übersetzer begutachtet
|
v
4.Regelmäßiges Syncen freigeschalteter Übersetzungen
an den offiziellen DDTP-Server
In Schritt 1 blieb das bisherige System erhalten, wobei die Datenbasis
unser RCS wäre (wobei aber nur »nicht-freigeschaltete« und
»nicht-übersetzte« Beschreibungen veränderbar wären).
In Schritt 2 würden diese Übersetzungen in unser Alioth-Projekt z.B.
einmal täglich integriert. Geänderte Übersetzungen oder neue
Übersetzungen wären dabei standardmäßig nicht freigeschaltet. Je nach
Art der Integration wären auch direkte Schreibzugriffe nach jeder
Änderung sinnvoll, damit 1 immer aktuell wäre.
In Schritt 3 lesen erfahrene Übersetzer diese Übersetzungen korrektur,
können dabei z.B. auch globales Suchen und Ersetzen durchführen, um
einheitlichen Stil zu erreichen oder auch, falls gewünscht, neue
Passagen übersetzen. Anschließend fügen Sie eine Markierung an alle
Beschreibungen an, die sie freischalten wollen. Mir schwebt da ein
Kommentar vor, bspw.
# Release: yes, kreutzm-guest
(das Format können wir natürlich noch besprechen).
Die Zugriffskontrolle regelt das VCS, in Schritt 1 kann höchstens nur eine
solche Zeile gelöscht, aber niemals gesetzt werden.
Gerne können auch mehrere solcher Zeilen gesetzt werden, um auch eine
Nachprüfung zu ermöglichen.
In Schritt 4 werden regelmäßig alle Übersetzungen, die über eine Zeile
der oa. Form verfügen, wie gehabt an das DDTP-Projekt weitergereicht,
und landen dann auf p.d.o. und in den Release.gz-Dateien, wie gehabt.
In der Form ständen sie auch wieder in Schritt 1 zur Verfügung, falls
wir das wollten (ich sähe da aber den Sinn nicht).
Aus meiner Sicht wäre das ein beherschbares System mit nur der
notwendigen Komplexität. Dennoch müsste es jemand implementieren :-((
Alternativ könnten jemand, der das System gut kennt, eventuell eine
Zeit lang Schritt 2 & 4 (halb-)manuell durchführen?
> > Hört sich für mich absolut gangbar an und nach einem brauchbaren
> > Vorschlag. Eine Diskussion, die in die ähnliche Richtung ging, gab es
> > schon, durch z.B. zwar eine weiterhin anonyme Erstübersetzung, aber
> > einem notwendigem Login fürs Weiterschieben.
>
> Ja, auf die (nicht notwendigerweise) anonyme Erstübersetzung von
> beliebigen Mitstreitern möchte ich nicht verzichten ...
Einverstanden. Denn überprüfen ist oft einfacher als selbst schreiben,
und im schlimmsten Fall würden wir im Begutachtungszyklus die
Übersetzung wieder löschen bzw. selber neu formulieren.
Ich habe mittlerweile einige Erfahrungen im Bearbeiten großer
Übersetzungsmengen (u.a. alte DSAs, alte News-Artikel, Dpkg-Handbuchseiten)
und würde mir zutrauen, mich auch hier mit dranzusetzen.
Viele Grüße
Helge
--
Dr. Helge Kreutzmann debian@helgefjell.de
Dipl.-Phys. http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
Help keep free software "libre": http://www.ffii.de/
Attachment:
signature.asc
Description: Digital signature