Hallo Andre, Michael, *,
On Monday 31 January 2005 20:29, Andre Schnabel wrote:
> >D.h. die Aenderungen zu verfolgen ist nur bei Korrekturen an im
> >wesentlichen fertigen Werken wirklich hilfreich, wo Fehler
> > gefunden werden sollen.
> >Wenn sich ein Dokument noch in der Erstellungsphase befindet
> > oder ein Lektor wesentliche inhaltliche Veraenderungen,
> > Verschiebungen oder Neuformulierungen vornimmt, ist die
> > Nuetzlichkeit eingeschraenkt. Zumindest bei mehr als zwei
> > Beteiligten. Das gilt auch fuer Veraenderungen am Layout.
> >Ist das erstmal richtig so und entspricht den Problemen bei der
> > letzten Bearbeitung?
> Soweit ich das sehe: ja.
bei mir ging es eigentlich nicht um den letzten Schritt. Wenn du nur
ins issue #31961 mit dem featureguide reinschaust, siehst du, dass
zwischendurch immer wieder ge�nderte Versionen von verschiedenen
Leuten einflie�en. Und ich fand es da dann z.T. schwierig, allen
�nderungen hinterherzukommen (sprich: auf dem Laufenden zu bleiben,
wo wer welche Fehler korrigiert hatte und wo wer �nderungen am Text
gemacht hatte, die in einer anderen Version nicht drin war). Dann
musstest du als urspr�nglicher �bersetzer nachher schauen, das
praktisch alle �nderungen wieder in so was wie einem
"Globaldokument" einflossen, was dann wieder ins issue kam ...
> >Und wenn ja, ist das vermeidbar?
> aus meiner sicht nur mit dem Ansatz von Thomas
> ("Bearbeitungskette") und Wolfgang ("Richtlinien f�r
> professionelle Dokumentation"). oder eben indem der "Manager"
> nachher viel Aufwand mit zusammenpuzzeln hat.
Den "Manager" wollte ich ja mit meiner "Bearbeitungskette" umgehen.
Sinn war eher, dass das eher nach dem folgenden Schema l�uft:
�bersetzer ruft Korrekturleser auf. 1. Korrekturleser schnappt sich
das Dokument, korrigiert es und sendet es dem 2., der es wiederum -
wenn erforderlich - den 3. sendet. Wenn der letzte Korrekturleser
das dann zu Ende korrigiert hat und meint, dass das Dokument o.k.
ist, wird's ins issue geh�ngt/wieder an den �bersetzer
zur�ckgesendet, der ins issue h�ngt ... Notfalls k�nnte dann noch
am Schluss noch der finale Korrekturleser gesucht werden, wenn der
3. meint, es w�re noch von N�ten. Oder aber, dass - falls n�tig -
noch jemand wie mein "Formatierungsk�nstler" Harald das dann auf
Formatierungsfehler �berpr�ft oder so (er k�nnte sich dann - wie
jetzt geschehen - auch als erster krallen und sendet es dann
weiter ....).
Vorteil w�re halt definitiv, das �bersetzer, Autoren (die das ja
auch betrifft) und im issue selbst nur das Anfangsdokument und das
Endprodukt verwalten m�ssen ... ;)
> Im Endeffekt l�uft es wohl darauf hinaus, dass sich ein Team
> findet, welches "gut miteinander kann".
Das kristallisiert sich ja meiner Meinung nach langsam heraus ... ;)
Bis dann
Thomas.
P.S.: Wir sollten aber wirklich mal zu einem konkreten Ende kommen,
sonst "traut" sich nachher keiner der Korrekturleser an den
featureguide heran und er liegt dann da bis zum
Sankt-Nimmerleinstag ... ;)
--
Let no guilty man escape.
-- U.S. Grant
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
