diff --git a/source/nl/1.0.0/index.html.haml b/source/nl/1.0.0/index.html.haml
index 614ea22..6cd83b0 100644
--- a/source/nl/1.0.0/index.html.haml
+++ b/source/nl/1.0.0/index.html.haml
@@ -149,85 +149,76 @@ version: 1.0.0
     Deprecations negeren
 
   %p
-    When people upgrade from one version to another, it should be
-    painfully clear when something will break. It should be possible to
-    upgrade to a version that lists deprecations, remove what's
-    deprecated, then upgrade to the version where the deprecations
-    become removals.
+    Wanneer mensen upgraden van de ene naar de andere versie,
+    moet het overduidelijk zijn als er iets niet meer zal werken.
+    Het moet mogelijk zijn om te upgraden naar een versie met deprications,
+    afhanlekijkheden van de deprications weg te halen, en vervolgens
+    de upgrade kunnen doen naar de versie waar de deprications removals zijn geworden.
 
   %p
-    If you do nothing else, list deprecations, removals, and any
-    breaking changes in your changelog.
-
+    Geef altijd op zijn minst de deprications, removals en changes met grote impact aan in je changelog.
 
   %h4#confusing-dates
     %a.anchor{ href: "#confusing-dates", aria_hidden: "true" }
-    Confusing Dates
+    Verwarrende datums
 
   %p
-    Regional date formats vary throughout the world and it's often
-    difficult to find a human-friendly date format that feels intuitive
-    to everyone. The advantage of dates formatted like
-    <code>2017-07-17</code> is that they follow the order of largest to
-    smallest units: year, month, and day. This format also doesn't
-    overlap in ambiguous ways with other date formats, unlike some
-    regional formats that switch the position of month and day numbers.
-    These reasons, and the fact this date format is an
-    #{link_to "ISO standard", iso} are why it is the recommended date
-    format for changelog entries.
+    Datum notaties verschillen van land tot land, en het is vaak moeilijk om
+    een notatie te vinden die makkelijk te lezen is en intuitief is voor iedereen.
+
+    Het voordeel van de notatie <code>2017-07-17</code> is dat het jaar, maand en dag
+    op volgorde van grootte laat zien. Daarom, en het feit dat dit een  #{link_to "ISO standaard", iso}
+    is, is dit de aanbevolen datum notatie voor changelog releases.
 
   %aside
-    There’s more. Help me collect these antipatterns by
-    = link_to "opening an issue", issues
-    or a pull request.
+    Dit is niet alles. Help mij antipatterns te verzamelen door
+    = link_to "een issue", issues
+    of een pull request aan te maken.
 
 .frequently-asked-questions
   %h3#frequently-asked-questions
     %a.anchor{ href: "#frequently-asked-questions", aria_hidden: "true" }
-    Frequently Asked Questions
+    Veel Gestelde Vragen
 
   %h4#standard
     %a.anchor{ href: "#standard", aria_hidden: "true" }
-    Is there a standard changelog format?
+    Is er een standaard changelog template?
 
   %p
-    Not really. There's the GNU changelog style guide, or the two-
-    paragraph-long GNU NEWS file "guideline". Both are inadequate or
-    insufficient.
+    Niet echt. Er is de GNU changelog style guide, en de twee paragrafen GNU NEWS bestand "richtlijnen".
+    Beiden zijn niet volledig genoeg.
 
   %p
-    This project aims to be
-    = link_to "a better changelog convention.", changelog
-    It comes from observing good practices in the open source
-    community and gathering them.
+    Dit project poogt
+    = link_to "een betere changelog standaard", changelog
+    te creëren. Dit op basis van bewezen "good practices" uit de open source wereld.
 
   %p
-    Healthy criticism, discussion and suggestions for improvements
-    = link_to "are welcome.", issues
+    Opbouwende kritiek, discussie en suggesties voor verbetering
+    = link_to "zijn welkom.", issues
 
 
   %h4#filename
     %a.anchor{ href: "#filename", aria_hidden: "true" }
-    What should the changelog file be named?
+    Wat zou de changelog bestandsnaam moeten zijn?
 
   %p
-    Call it <code>CHANGELOG.md</code>. Some projects use
-    <code>HISTORY</code>, <code>NEWS</code> or <code>RELEASES</code>.
+    Noem het <code>CHANGELOG.md</code>. Sommige projecten gebruiken
+    <code>HISTORY</code>, <code>NEWS</code> of <code>RELEASES</code>.
 
   %p
-    While it's easy to think that the name of your changelog file
-    doesn't matter that much, why make it harder for your end users to
-    consistently find notable changes?
+    Je kan denken dat de bestandsnaam niet heel belanrijk is,
+    maar waarom zou je het de eindgebruikers moeilijker maken om de changelog te vinden?
 
   %h4#github-releases
     %a.anchor{ href: "#github-releases", aria_hidden: "true" }
-    What about GitHub Releases?
+    Wat denk je van GitHub Releases?
 
   %p
-    It's a great initiative. #{link_to "Releases", ghr} can be used to
-    turn simple git tags (for example a tag named <code>v1.0.0</code>)
-    into rich release notes by manually adding release notes or it can
-    pull annotated git tag messages and turn them into notes.
+    Het is een goed initiatief. #{link_to "Releases", ghr} kan gebruikt worden
+    om simpele git tags (bijvoorbeeld een tag met naam  <code>v1.0.0</code>)
+    te veranderen in uitgebreide release notes door deze handmatig toe te voegen of
+    door geannoteerde git tag berichten te gebruiken om release notes te genereren.
 
   %p
     GitHub Releases create a non-portable changelog that can only be