diff --git a/source/de/1.0.0/index.html.haml b/source/de/1.0.0/index.html.haml
index 6ee1485..5fae83d 100644
--- a/source/de/1.0.0/index.html.haml
+++ b/source/de/1.0.0/index.html.haml
@@ -42,8 +42,8 @@ version: 1.0.0
Was ist der Zweck eines Changelogs?
%p
- Ein Changelog soll es Benutzern und Entwicklern einfacher machen, gerade die
- beachtenswerten Änderungen, die zwischen Veröffentlichungen (oder Versionen)
+ 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
@@ -110,7 +110,7 @@ version: 1.0.0
Wie kann ich den Aufwand der Changelog-Pflege so klein wie möglich halten?
%p
- Habe immer einen Unreleased-Abschnitt über der neusten Version,
+ Habe immer einen Unreleased-Abschnitt über der neusten Version,
um zukünftige Änderungen im Auge zu behalten.
%p Dies hat zwei Vorteile:
@@ -119,7 +119,7 @@ version: 1.0.0
%li
Menschen können sehen, welche Änderungen sie mit dem nächsten Release zu erwarten haben.
%li
- Wenn der Zeitpunkt für den Release gekommen ist, kannst du den Inhalt des
+ Wenn der Zeitpunkt für den Release gekommen ist, kannst du den Inhalt des
Unreleased-Abschnitts in den neuen Release-Abschnitt verschieben.
.bad-practices
@@ -135,8 +135,8 @@ version: 1.0.0
Einen Diff von Commit-Logs ausgeben
%p
- Commit-Logs in einem Changelog sind eine schlechte Idee: Sie beinhalten lauter
- überflüssige Dinge, wie Merge-Commit, Commits mit schlechten Bezeichnungen,
+ Commit-Logs in einem Changelog sind eine schlechte Idee: Sie beinhalten lauter
+ überflüssige Dinge, wie Merge-Commit, Commits mit schlechten Bezeichnungen,
Änderungen an der Dokumentation, etc.
%p
@@ -144,8 +144,8 @@ version: 1.0.0
Manche Projekte haben saubere Commits, andere nicht.
%p
- Der Sinn eines Changelog-Eintrags ist die Dokumentation der merkbaren
- Unterschiede, die meist über mehrere Commits hinweg entstanden sind, dem
+ Der Sinn eines Changelog-Eintrags ist die Dokumentation der merkbaren
+ Unterschiede, die meist über mehrere Commits hinweg entstanden sind, dem
Endnutzer klar und deutlich zu kommunizieren.
@@ -157,7 +157,7 @@ version: 1.0.0
Wenn der Endnutzer auf eine neue Version upgradet, sollte ihm unmissverständlich
klar gemacht werden, wenn etwas kaputt gehen wird. Es sollte immer möglich sein,
zu einer Version zu upgraden, die die zu entfernenden Features auflistet, um so
- in seinem Source Code auf diese Features zu verzichten. Anschließend sollte man
+ in seinem Source Code auf diese Features zu verzichten. Anschließend sollte man
auf eine Version upgraden können, in der die Features entfernt wurden.
%p
@@ -170,7 +170,7 @@ version: 1.0.0
Verwirrende Datumsformate
%p
- In den USA setzen die Menschen den Monat an den Anfang eines Datums
+ In den USA setzen die Menschen den Monat an den Anfang eines Datums
(06-02-2012 für den 2. Juni 2012), wohingegen viele Menschen
im Rest der Welt ein roboterhaft aussehendes 2 June 2012
schreiben, aber es völlig unterschiedlich aussprechen. 2012-06-02
@@ -180,7 +180,7 @@ version: 1.0.0
%aside
Es gibt sicher noch mehr. Hilf mir alle schlechten Tipps zu sammeln, indem du
- = link_to "ein Issue eröffnest", "#issues"
+ = link_to "ein Issue eröffnest", issues
oder einen Pull-Request erstellst.
.frequently-asked-questions
@@ -193,8 +193,8 @@ version: 1.0.0
Gibt es ein standardisiertes Changelog-Format?
%p
- Leider nicht. Es gibt zwar den GNU Changelog Styleguide oder den
- zwei Absätze langen GNU NEWS-Datei "Leitfaden". Beide sind aber
+ Leider nicht. Es gibt zwar den GNU Changelog Styleguide oder den
+ zwei Absätze langen GNU NEWS-Datei "Leitfaden". Beide sind aber
unzureichend.
%p
@@ -219,7 +219,7 @@ 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 einen einheitlichen Namen
+ die Änderungen des Projekts zu finden, indem man einen einheitlichen Namen
verwendet?
@@ -228,21 +228,21 @@ version: 1.0.0
Was ist mit GitHub Releases?
%p
- Prinzipiell sind #{link_to "GitHub Releases", ghr} eine gute Sache.
- Sie können dazu benutzt werden, um einfache Git Tags (zum Beispiel einen
- Tag namens v1.0.0) mit vielen Hinweisen zum Release
+ Prinzipiell sind #{link_to "GitHub Releases", ghr} eine gute Sache.
+ 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
+ Git Tag Nachricht schreibt, wo sie durch GitHub automatisch in die
Release-Notizen gesetzt werden.
%p
- Leider lassen sich GitHub Releases aber nicht so einfach exportieren
+ Leider lassen sich GitHub Releases aber nicht so einfach exportieren
und sind nur über GitHub selber zu lesen. Man kann sie auch so gestalten,
dass sie dem Keep a Changelog Format sehr ähnlich sehen, aber dazu betreibt
man in der Regel einen größeren Aufwand.
%p
- Die derzeitige Version der GitHub Releases sind außerdem nicht leicht
+ Die derzeitige Version der GitHub Releases sind außerdem nicht leicht
durch die Endnutzer zu finden, ganz im Gegenteil zu den typischerweise
großgeschriebenen Dateien (README, CONTRIBUTING, etc.).
Ein weiterer kleiner Nachteil ist, dass das Web Interface zurzeit keinen Link
diff --git a/source/en/1.0.0/index.html.haml b/source/en/1.0.0/index.html.haml
index 08f467d..32c7291 100644
--- a/source/en/1.0.0/index.html.haml
+++ b/source/en/1.0.0/index.html.haml
@@ -177,7 +177,7 @@ version: 1.0.0
%aside
There’s more. Help me collect these antipatterns by
- = link_to "opening an issue", "#issues"
+ = link_to "opening an issue", issues
or a pull request.
.frequently-asked-questions
diff --git a/source/sv/1.0.0/index.html.haml b/source/sv/1.0.0/index.html.haml
index aeb27c7..2aedc33 100644
--- a/source/sv/1.0.0/index.html.haml
+++ b/source/sv/1.0.0/index.html.haml
@@ -174,7 +174,7 @@ version: 1.0.0
%aside
Det finns mer. Hjälp mig att samla dessa antimönster genom att
- = link_to "skapa ett issue", "#issues"
+ = link_to "skapa ett issue", issues
eller en pull requests
.frequently-asked-questions
diff --git a/source/tr-TR/1.0.0/index.html.haml b/source/tr-TR/1.0.0/index.html.haml
index dc0ce95..cb4f8b1 100644
--- a/source/tr-TR/1.0.0/index.html.haml
+++ b/source/tr-TR/1.0.0/index.html.haml
@@ -175,8 +175,8 @@ version: 1.0.0
kayıtları için önerilen tarih biçimidir.
%aside
- Mutlaka dahası da vardır. Benzer durumları toplamam için
- = link_to "bir çağrı açın", "#issues"
+ Mutlaka dahası da vardır. Benzer durumları toplamam için
+ = link_to "bir çağrı açın", issues
ya da bir çekme isteği gönderin.
.frequently-asked-questions
@@ -238,7 +238,7 @@ version: 1.0.0
Ayrıca GitHub dağıtımlarının şu anki hali son kullanıcılar tarafından
çok kolay bulunabilir değil. Tipik büyük harfli dosyalar
(README, CONTRIBUTING, vb.) daha çok göze
- çarpıyor. Bir başka konu da, mevcut arayüz her dağıtım arasındaki
+ çarpıyor. Bir başka konu da, mevcut arayüz her dağıtım arasındaki
commit kayıtlarına bağlantı vermeye izin vermiyor..
%h4#automatic