diff --git a/source/de/1.0.0/index.html.haml b/source/de/1.0.0/index.html.haml
index aecdd00..68596fd 100644
--- a/source/de/1.0.0/index.html.haml
+++ b/source/de/1.0.0/index.html.haml
@@ -33,25 +33,26 @@ version: 1.0.0
     Was ist ein Changelog?
 
   %p
-    Ein Changelog ist eine Datei, welche eine handgepflegte, chronologisch sortierte
-    Liste aller erheblichen Änderungen enthält, die zwischen Veröffentlichungen (oder Versionen)
-    des Projekts umgesetzt wurden.
+    Ein Changelog ist eine Datei, die eine handgepflegte, chronologisch sortierte
+    Liste aller erheblichen Änderungen enthält, die zwischen einzelnen Veröffentlichungen
+    (oder Versionen) des Projekts umgesetzt wurden.
 
   %h3#why
     %a.anchor{ href: "#why", aria_hidden: "true" }
     Was ist der Zweck eines Changelogs?
 
   %p
-    Es Benutzern und Entwicklern einfacher zu machen, gerade die beachtenswerten Änderungen, welche
-    zwischen Veröffentlichungen (oder Versionen) des Projekts gemacht wurden, zu sehen.
+    Ein Changelog soll es  Benutzern und Entwicklern einfacher machen, gerade die 
+    beachtenswerten Änderungen, die zwischen Veröffentlichungen (oder Versionen) 
+    des Projekts gemacht wurden, zu sehen.
 
   %h3#who
     %a.anchor{ href: "#who", aria_hidden: "true" }
     Wer braucht schon ein Changelog?
 
   %p
-    Menschen brauchen es. Seien es Konsumenten oder Entwickler, der Endnutzer der Software
-    sind Menschen, die es interessiert, was in der Software ist. Wenn sich die Software ändert,
+    Menschen brauchen es. Seien es Konsumenten oder Entwickler, die Endnutzer der Software
+    sind Menschen, die es interessiert, was in der Software passiert. Wenn sich die Software ändert,
     dann wollen diese Menschen wissen, wie und warum sie sich ändert.
 
 .good-practices
@@ -69,15 +70,15 @@ version: 1.0.0
     %li
       Für jede einzelne Version sollte es einen Eintrag geben.
     %li
-      Änderungen des selben Art sollten in Bereiche gruppiert werden.
+      Änderungen der selben Art sollten in Bereiche gruppiert werden.
     %li
-      Versionen und Bereiche sollten sollten verlinkt werden können.
+      Versionen und Bereiche sollten verlinkt werden können.
     %li
       Die neuste Version kommt als erstes.
     %li
       Das Release-Datum jeder Version muss angegeben sein.
     %li
-      Gibt ab, ob du dich an die #{link_to "Semantische Versionierung", semver} hältst.
+      Gib ab, ob du dich an die #{link_to "Semantische Versionierung", semver} hältst.
 
   %a.anchor{ href: "#types", aria_hidden: "true" }
   %h4#types Arten von Änderungen
@@ -190,12 +191,9 @@ version: 1.0.0
 
   %h4#standard
     %a.anchor{ href: "#standard", aria_hidden: "true" }
-    Gibt es ein standardisiertes Changelog-Format
+    Gibt es ein standardisiertes Changelog-Format?
 
   %p
-    Not really. There's the GNU changelog style guide, or the two-
-    paragraph-long GNU NEWS file "guideline". Both are inadequate or
-    insufficient.
     Leider nicht. Es gibt zwar den GNU Changelog Styleguide oder den 
     zwei Absätze langen GNU NEWS-Datei "Leitfaden". Beide sind aber 
     unzureichend.
@@ -222,7 +220,8 @@ version: 1.0.0
   %p
     Man könnte zwar meinen, dass der Name der Changelog-Datei keine große
     Bedeutung hat, aber warum sollte man es den Endnutzern nicht einfach machen,
-    die Änderungen des Projekts zu finden, indem man einheitlichen Namen verwendet?
+    die Änderungen des Projekts zu finden, indem man einen einheitlichen Namen 
+    verwendet?
 
 
   %h4#github-releases
@@ -231,7 +230,7 @@ version: 1.0.0
 
   %p
     Prinzipiell sind #{link_to "GitHub Releases", ghr} eine gute Sache. 
-    Sie können dazu benutzt werden, um einfache Git Tags (zum Beispiel ein 
+    Sie können dazu benutzt werden, um einfache Git Tags (zum Beispiel einen 
     Tag namens <code>v1.0.0</code>) mit vielen Hinweisen zum Release 
     auszustatten, indem man sie manuell bearbeitet, oder die Änderungen in eine
     Git Tag Nachricht schreibt, wo sie durch GitHub automatisch in die 
@@ -289,7 +288,7 @@ version: 1.0.0
 
   %p
     Klar. Es gibt immer gute Gründe, ein Changelog zu verbessern. Ich öffne
-    regelmässig Pull Requests um Open-Source-Projekten mit schlecht gewarteten
+    regelmässig Pull Requests, um Open-Source-Projekten mit schlecht gewarteten
     Changelogs fehlende Releases hinzuzufügen.
 
   %p
@@ -303,11 +302,11 @@ version: 1.0.0
     Wie kann ich mithelfen?
 
   %p
-    Dieses Dokument ist nicht die <strong>Wahrheit</strong>; Es ist meine wohl überlegte Meinung,
+    Dieses Dokument ist nicht die <strong>Wahrheit</strong>. Es ist meine wohl überlegte Meinung,
     zusammen mit von mir zusammengetragenen Informationen und Beispielen.
 
   %p
-    So möchte ich erreichen, dass die Community einen Konsens finden. Ich glaube, dass
+    So möchte ich erreichen, dass die Community einen Konsens findet. Ich glaube, dass
     die Disskussion genauso wichtig ist wie das Endergebnis.
 
   %p