Re: DDTS-Übersetzungen und starke Qualitätsmängel
On 20/05/08 21:25 +0200, Helge Kreutzmann wrote:
> 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?
Im Moment? Gar nicht, die bleiben so. Wenn jemand ueber einen Fehler
stolpert, soll er einen Fehlerbericht aufmachen bzw. sich auf der Liste
beschweren.
Das handhaben wir bei paketierter Software ja noch viel grosszuegiger:
wenn Du jeden Fehler beseitigst, der upstream aufschlaegt, kannst Du nur
noch Snapshots paketieren. Und das macht ja auch keiner.
> Das hieße ja, die Übersetzungen einmal komplett korrektur zu lesen,
> oder?
Das werden wir nicht leisten koennen, denke ich zumindest.
> > > > 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.
EDITOR $(grep -l STRING *)
Oeffnet nur die Dateien, in denen STRING auch gefunden 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.
> >
> > 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.
Kannst Du. Ich habe die privaten Depots nicht erwaehnt, aber jeder hat
natuerlich seine eigenen privaten Depots auf seinem Rechner. Sprich, Du
checkst das auf Deinem Rechner ein, so oft Du willst und schiebst die
Sachen, die fertig sind, in Dein oeffentliches Depot.
> Und der zentrale Server ist zwar ein Ausfallspunkt (darum ging es
> Dir?)
Das verstehe ich nicht, was meinst Du?
> 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.
Dann musst Du Dich mit den Leuten absprechen, dass niemand an Sachen
arbeitet, an denen Du arbeitest. Im Prinzip funktioniert das aber ja
jetzt schon. Was Du aber in jedem Fall brauchen wirst, ist der
massgebliche Zweig, auf dem Translation-de beruht.
> > 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).
Mit "Deinem oeffentlichen Depot" meine ich den Platz, wo Du Deine Sachen
veroeffentlichst. Das sollte auch auf Alioth gehen. Wenn die Leute
anfangen muessen, private Webserver zu betreuen, laeuft was schief.
> > 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.
Nein, direkt da rein schreiben soll niemand. Das hat mehr mit dem
Vermeiden von Rollen (der hat aber Schreibrechte und ich nicht) als mit
der technischen Seite zu tun.
Was ich halt vermeiden sind, sind grosse Skripte, um die sich dann doch
wieder jemand kuemmern muss.
> > 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 bedeutet, dass man die Anzahl der vertrauenswuerdigen Leute, die
einen Patch haben muessen, auf 1 setzt. Das ist im Prinzip der jetzige
Stand (Leute mit Schreibrechten koennen alles vorhergehende
ueberschreiben).
> 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).
Wie gesagt, das halte ich fuer machbar. Das Problem ist die Disziplin:
erst das alte uebernehmen, dann die neuen Aenderungen drueberschreiben
und die Sachen in das eigene oeffentliche Depot hoch schieben.
Sonst kann das RCS nicht entscheiden, was wohin gehoert.
Thomas
Reply to: