From 1e37b75b1ecdae00cfdce6324531c92ec6c84c7c Mon Sep 17 00:00:00 2001 From: Artur Weigandt Date: Tue, 20 Jun 2017 21:22:50 +0200 Subject: [PATCH] Fixes after review --- source/de/1.0.0/index.html.haml | 37 ++++++++++++++++----------------- 1 file changed, 18 insertions(+), 19 deletions(-) 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 v1.0.0) 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 Wahrheit; Es ist meine wohl überlegte Meinung, + Dieses Dokument ist nicht die Wahrheit. 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