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).
Was man deaktivieren muss ist die automatische Uebernahme der
Web-Uebersetzungen.
> > 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.
> 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.
> 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):
Ein Tab sind 8 Leerzeichen in der folgenden Grafik. A und B seien
"zugelassene" Uebersetzer, 'Web' ist die derzeitige anonyme
Schnittstelle, C ein weiterer (noch nicht) zugelassener Uebersetzer:
im Netz zugaenglich: Web A B C
| | | |
| | | |
die verschiedenen
Zweige auf die eigene
lokale Platte
runterladen
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:
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).
Ein Skript sieht sich die oeffentlichen Repos von A, B und
(gegebenenfalls) I an und zieht alle Patches, die in genuegend[2] der Repos
drin sind, in das offizielle Repo auf dem DDTP-Server. Aus diesem Repo
kommen dann die Daten fuer Translation-de.
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.
[1] Wichtig dabei ist, dass zugelassene Uebersetzer nur
korrektur-gelesene Sachen veroeffentlichen. Man kann natuerlich 10
Patches gleichzeitig runterladen und dann eben 10 Korrekturen
einchecken.
[2] 'Genuegend' ist dann das Mass fuer die QA, die wir wollen. Reicht
ein Uebersetzer, sollen es drei in ihrem Repo drin haben...
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.
Was wir dabei von DDTP brauchen:
- Die Web-Schnittstelle muss als Repository zur Verfuegung stehen
- Und die Uebernahme in Translation-de muss ueber ein Skript laufen,
das bestimmte Repos abklappert (falls das fuer die einfacher ist,
kann man sicherlich auch ueber ein Alioth-Projekt einen Master zur
Verfuegung stellen, aus dem DDTP dann nur noch zieht; das Skript
liefe dann auf Alioth).
Was wir verlieren: anonymes Korrekturlesen (aber das funktioniert ja
scheinbar sowieso nicht).
Thomas
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
