Hallo,
On Tue, May 20, 2008 at 09:06:25PM +0200, Thomas Weber wrote:
> On 20/05/08 19:31 +0200, Helge Kreutzmann wrote:
> > Ich unterstütze daher den Vorschlag, erst mal die Reißleine für die
> > übersetzten Paketbeschreibungen zu ziehen und sie nicht mehr
> > anzuzeigen.
>
> Das sehe ich allerdings anders. Gut, da sind einige Boecke drin, aber
> andere sind aus meiner Sicht auch vollkommen in Ordnung (ich blaettere
> gerade durch Translation-de).
Wie willst Du die Guten von den Böcke trennen? Das hieße ja, die
Übersetzungen einmal komplett korrektur zu lesen, oder?
> Was man deaktivieren muss ist die automatische Uebernahme der
> Web-Uebersetzungen.
Ack.
> > > 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?)?
>
> Ich denke, dass einzelne Dateien besser sind. Das reduziert die Chance
> auf Konflikte doch erheblich.
Ja, erschwert aber auch das Vereinheitlichen. So kann ich bei einer
großen Datei schnell nach einer bestimmte Zeichenkette suchen und
prüfen, ob diese immer einheitlich übersetzt wurde.
> > Mir gefällt das, aber es muss maschinenlesbar sein.
>
> Ich wuerde das gerne so umsetzen, dass das RCS den Verwaltungsaufwand
> uebernimmt. Wenn also eine Uebersetzung schlecht ist, nimmt man den
> entsprechenden Patch trotzdem auf und checkt danach eine Korrektur ein.
> Wenn jemand anders synchronisiert, kriegt er dann direkt beide Patches.
Soll mir recht sein.
>
> > 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
>
> Ich stelle mir da mehr Parallelitaet vor (das benoetigt aber dann ein
> verteiltes RCS):
Ich persönlich würde gerne meine Änderungen irgendwo »einchecken«,
ohne selber etwas veröffentlichen zu müssen. Und der zentrale Server
ist zwar ein Ausfallspunkt (darum ging es Dir?), aber er erledigt auch
nett die Authentifizierungs- und Autorisierungsproblematik. Und mit
einem hinreichend leistungsfähigen RCS sollte die Parallelität auch
i.O. sein. Ich habe auch kein Problem, dass »C« seine Änderungen in
seinem RCS bereitstellt, und ich mir regelmäßig dort die neusten
Sachen abhole und dann in das zentrale Depot einspiele (bis ich C gut
genug vertraue, und für ihn einen Zugang beantrage).
> Man uebernimmt die Patches von A und B ins eigene private Repo, denen
> vertraut man ja. Dann sieht man sich an, was Web und C gemacht haben:
Ich würde auf meiner Seite gerne nur mit einem Depot arbeiten, falls
ich nicht (wie oben) explizit jemanden betreue. Der Aufwand sollte bei
mir möglichst gering sein. Und ich rechne auch nicht mit vielen
Zweigen (huch, ich nehme A und B, und Du aber A und B', und dann sehen
wir mal, wer von uns beiden die bessere Übersetzung hat ...).
> dabei geht man dann stueckweise vor, d.h. man nimmt einen Patch auf und
> checkt die Korrektur ein.[1] Beides zusammen stellt man dann auf seinem
> oeffentlichen Repo zur Verfuegung (das sei jetzt mal I).
Bitte nix was ich zwingend hosten muss (wäre deutlich mehr Aufwand).
> Der Unterschied, ob I ein zugelassener Uebersetzer ist oder nicht,
> ergibt sich nur fuer das Skript und dem Vertrauen der anderen Leute
> in das oeffentliche Repo von I. Die eigene Arbeitsweise ist davon
> unabhaengig.
Das können wir auch in das zentrale Depot einkodieren. Wenn »I« i.O.
ist, dann darf er/sie halt schreiben.
> Eine Schwachstelle hat das obige System: wenn A einen Fehler eincheckt,
> B synchronisiert und eine Korrektur eincheckt, A die aber nicht
> uebernimmt: dann wird das Skript den fehlerhaften Patch bei beiden sehen
> und den ins offizielle Repo uebernehmen. Da die Korrektur aber nur in
> einem Repo vorkommt, bleibt die bis auf weiteres unbeachtet. Im Prinzip
> ist das ein Zwang zum Konsens.
Das gefällt mir nicht. Wenn ich einen Tippfehler sehe, dann würde ich
ihn gerne irgendwo ultimativ ändern, ohne zu hoffen, dass ihn X andere
Leute möglichst meine Korrektur übernehmen, damit er aktiv wird. Das
klappt im Web-CVS ganz wunderbar (dort ist das Skript der WML-Lauf,
der die bearbeiteten Quelldateien regelmäßig konvertiert und auf den
Webserver bringt).
> Was wir verlieren: anonymes Korrekturlesen (aber das funktioniert ja
> scheinbar sowieso nicht).
Darin sehe ich kein Problem.
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