Korrekturlesen der Kapitel #111
Comments
|
Neben den Anpassungen, die ich schon für die einleitenden Kapitel sowie für Kapitel 1 in dem Pull Request übermittelt habe, habe ich noch weitere Dinge (bisher mit Kommentaren im Quellcode) "markiert", wo ich mir nicht sicher bin, d.h. Punkte, die ich gerne zur Diskussion stellen möchte. Die Frage ist, wie soll ich hiermit umgehen? Für mich am Einfachsten wäre einen Merge des Pull Requests zu dem Kapitel abzuwarten und dann einen weiteren Pull Request als Draft zu stellen, in dem die Kommentare dann zu lesen sind. Ein Beispiel wäre diff --git a/book/introduction.asc b/book/introduction.asc
index 6019f41..8dd0f13 100644
--- a/book/introduction.asc
+++ b/book/introduction.asc
@@ -11,6 +11,9 @@ In *Kapitel 1*, werden wir Version Control Systeme (VCSs) und die Grundlagen von
Dann werden wir beschreiben, wie Sie Git herunterladen und zum ersten Mal einrichten können, wenn Sie es noch nicht auf Ihrem System installiert haben.
In *Kapitel 2* gehen wir auf die grundlegende Git-Verwendung ein – wie Sie Git in den 80% der Fälle verwenden, denen Sie am häufigsten begegnen.
+// "Veränderungen" klingt nicht gut -->
+// "... Dateien anzupassen und Änderungen beizutragen." oder
+// "... Dateien anzupassen und Anpassungen beizutragen."
Nachdem Sie dieses Kapitel gelesen haben, sollten Sie in der Lage sein, ein Repository zu klonen, zu sehen, was in der Verlaufshistorie des Projekts passiert ist, Dateien zu ändern und Veränderungen beizutragen.
Angenommen dieses Buch geht in diesem Augenblick in Flammen auf, dann sollten Sie trotzdem schon in der Lage sein, so weit bei der Anwendung von Git zu helfen, um die Zeit zu überbrücken bis ein neues Exemplar dieses Buches beschafft ist.Eine Listung in Form des Diffs wie oben wäre die nächst simplere Möglichkeit. Verzichten würde ich gerne auf eine Listung in der Form progit2-de/book/introduction.asc Line 14 in d322726 Hier finde ich, dass das Wort "Veränderungen" komisch klingt. Vielleicht wäre
oder
besser. weil dies sehr aufwändig ist. Wie ist eure Meinung? Habt ihr andere Vorschläge wie hier verfahren werden kann? |
|
Das Kommentieren innerhalb der Quelldateien ist kontraproduktiv bei der Art wie die Übersetzung aus der englischen Version angelegt ist. Es ist wichtig, das sich die Zeilennummern der Quelldateien entsprechen. So können mögliche Commits auf der englischen Seite leichter in die deutsche Datei eingebunden werden. Mit zusätzlichen Kommentarzeilen wird es schwerer den richtigen Ort der Anpassung zu finden. Was spricht dagegen, dass du deine bevorzugte Variante committest und in einem zusätzlichen Diskussionskommentar zur Zeile die Alternative nennst? |
Aah, das war mir nicht bewusst. Die (meisten) Kommentare wären natürlich nur temporär, bis sich auf eine Lösung geeinigt wurde, die per "suggestion"-Code in einem Kommentar geschrieben werden kann. Auf diese Weise ist der Aufwand für alle Seiten (denke ich) am geringsten. Bei manchen Stellen habe ich nämlich einfach nur eine Frage, und dann kann ich natürlich keinen Gegenvorschlag machen oder einen Diskussionskommentar hinzufügen. Ich schlage vor, dass wir meine Variante einmal für die einleitenden Kapitel und Kapitel 1 exerzieren/testen (das sind 4 Stellen), um zu sehen, ob der Weg praktikabel ist. Wenn nicht, versuchen wir deinen (@max123kl) Weg. Einverstanden? |
|
Nach meiner bescheidenen Erfahrung passiert es leicht, dass die "Inline"-Kommentare einfach vergessen werden sie wieder zu löschen. Da sie nach dem ersten Review auf GitHub nicht mehr als neu oder modifiziert markiert werden, fallen sie weniger auf. Eine Idee wäre (nicht getestet), am Ende der fraglichen Zeile ein Leerzeichen einzufügen (das wird vom Parser automatisch wieder gelöscht) und dann für diese Zeile hier in der Diskussion einen Kommentar zu hinterlassen. |
|
Mein Editor löscht automatisch Leerzeichen am Ende einer Zeile ... Dein beschriebenes Problem würde es nur dann geben, wenn gemerged wird, bevor alle Kommentare wieder entfernt sind. Falls es dazu kommen sollte, werde ich mich melden. Dazu sollte es aber nicht kommen, wenn weiterhin so zügig auf meine PRs etc. geantwortet wird, wie bisher. Ich erstelle gleich mal einen PR mit den 4 Kommentaren. Wir schaffen das ;) |
|
Hallo, ich beschäftige mich seit einigen Monaten mit dem Thema GIT und bin sozusagen noch ein Neuling auf diesem Gebiet. Daher lese ich die deutsche Übersetzung und notiere mir Verbesserungen in der Grammatik und Formulierungen. |
|
@arohde69 |
|
Aber sicher doch. Hoffentlich "notierst" du die Verbesserungen direkt im Code und nicht irgendwo anders. Darfst direkt einen Pull Request mit deinen Änderungen stellen, das ist (für uns) am einfachsten. Wenn du Hilfe brauchst, erklären wir dir gerne, wie das geht. Sag uns aber dafür bitte, was du schon gemacht hast und wo du hängst.
|
|
Eine kleine Ergänzung zur beschriebenen Vorgehensweise von Mo-Gul: |
Zu eurer Information:
Ich bin noch relativer Git-Neuling (außer commit, push, pull kann ich eigentlich nichts), was auch der Grund ist, dass ich das Buch lese. Ich bitte also um Nachsicht, sollte ich zwischendurch etwas durcheinander bringen. Nehme dann gerne Ratschläge an, wie ich es beim nächsten Mal besser machen kann oder wie ich ein evtl. Durcheinander wieder geraderücken kann.
Korrekturen für
The text was updated successfully, but these errors were encountered: