progit2-de
progit2-de copied to clipboard
progit
Korrekturlesen der Kapitel
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
- [x] Einleitungsseiten/allgemeine Seiten
- [x] Kapitel 1
- [x] Kapitel 2
- [ ] Kapitel 3
- [ ] Kapitel 4
- [ ] Kapitel 5
- [ ] Kapitel 6
- [ ] Kapitel 7
- [ ] Kapitel 8
- [ ] Kapitel 9
- [ ] Kapitel 10
- [ ] Anhang A
- [ ] Anhang B
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
https://github.com/progit/progit2-de/blob/d322726c91ae44fa9adbd45baf2df518581f1caa/book/introduction.asc#L14
Hier finde ich, dass das Wort "Veränderungen" komisch klingt. Vielleicht wäre
... Dateien anzupassen und Änderungen beizutragen.
oder
... Datien anzupassen und Anpassungen beizutragen.
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? Ein "Draft"-PR oder, wie ich es schon öfter gesehen habe, ein vorangestelltes [WiP] (Work in Progress) im Titel des Commits signalisieren ja beide, dass die Arbeit noch nicht zum Mergen bereit ist.
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.
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. Daher meine Frage, ob noch Korrekturen zum Kapitel 1 in diesem Issue behandelt werden?
@arohde69 Das Buch ist ein „lebender Organismus“, d.h. es wird immer neue Anpassungen geben. Momentan werden im englischen Repo einige neue Texte diskutiert. Sobald die dort gemergt wurden, können die auch hier eingepflegt werden. Genauso verhält es sich mit den deutschen Texten. Wenn du bessere Formulierungen/Übersetzungen hast, dann starte einen Pull Request und beschreibe am besten im Kommentar deinen Vorschlag – falls er nicht selbsterklärend ist.
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.
- Repository geforkt
- geforktes Repository auf deinen Rechner geklont
- Änderungen gemacht
- zu deinem geforkten Repository commited
- Pull Request erstellt
Eine kleine Ergänzung zur beschriebenen Vorgehensweise von Mo-Gul: Wenn du Änderungen machen willst, dann erstelle vorher einen neuen Branch (Name egal) und mache die Anpassung dort. So vermeidest du, dass dein Master-Branch nicht mehr aktuell ist, falls dein Vorschlag nicht angenommen werden sollte.