From fa160598f3603f81eb22eb7cc10ea13e6003267a Mon Sep 17 00:00:00 2001 From: Jasper Krielaars Date: Thu, 21 Sep 2017 16:58:11 +0200 Subject: [PATCH 1/6] Added NL version of the main page. Translation in progress. --- source/nl/1.0.0/index.html.haml | 312 ++++++++++++++++++++++++++++++++ 1 file changed, 312 insertions(+) create mode 100644 source/nl/1.0.0/index.html.haml diff --git a/source/nl/1.0.0/index.html.haml b/source/nl/1.0.0/index.html.haml new file mode 100644 index 0000000..614ea22 --- /dev/null +++ b/source/nl/1.0.0/index.html.haml @@ -0,0 +1,312 @@ +--- +description: Keep a Changelog +title: Keep a Changelog +language: nl +version: 1.0.0 +--- + +- changelog = "https://github.com/olivierlacan/keep-a-changelog/blob/master/CHANGELOG.md" +- gemnasium = "https://gemnasium.com/" +- gh = "https://github.com/olivierlacan/keep-a-changelog" +- issues = "https://github.com/olivierlacan/keep-a-changelog/issues" +- semver = "http://semver.org/" +- shields = "http://shields.io/" +- thechangelog = "http://5by5.tv/changelog/127" +- vandamme = "https://github.com/tech-angels/vandamme/" +- iso = "http://www.iso.org/iso/home/standards/iso8601.htm" +- ghr = "https://help.github.com/articles/creating-releases/" + +.header + .title + %h1 Houd een Changelog bij + %h2 Laat je vrienden geen git logs in changelogs dumpen. + + = link_to changelog do + Versie + %strong= current_page.metadata[:page][:version] + + %pre.changelog= File.read("CHANGELOG.md") + +.answers + %h3#what + %a.anchor{ href: "#what", aria_hidden: "true" } + Wat is een changelog? + + %p + Een changelog is een bestand met een zorgvuldig samengestelde, chronologische lijst + van noemenswaardige aanpassingen voor elke versie van een project. + + %h3#why + %a.anchor{ href: "#why", aria_hidden: "true" } + Waarom een changelog bijhouden? + + %p + Om het makkelijker te maken voor gebruikers en programmeurs om precies te zien welke + noemenswaardige aanassingen er gedaan zijn tussen elke release (of versie) van het project. + + %h3#who + %a.anchor{ href: "#who", aria_hidden: "true" } + Wie heeft een changelog nodig? + + %p + Mensen hebben dat nodig. Of het nou consumenten of developers zijn, eindgebruikers van + software zijn mensen die er om gevenwat er in de software zit die ze gebruiken. + Als de software veranderd, wil men weten wat en hoe. + +.good-practices + %h3#how + %a.anchor{ href: "#how", aria_hidden: "true" } + Hoe maak ik een goed changelog? + + %h4#principles + %a.anchor{ href: "#principles", aria_hidden: "true" } + Richtlijnen + + %ul + %li + Changelogs zijn voor mensen, niet voor machines. + %li + Er zou een XXX moeten zijn voor elke versie. + There should be an entry for every single version. + %li + Aanpassingen van het zelfde type moeten gegroepeerd worden. + %li + Versies en secties souden linkbaar moeten zijn. + %li + De laatste versie staat bovenaan. + %li + De release datum van elke versie word weergegeven. + %li + Geef aan of je #{link_to "Semantic Versioning", semver} gebruikt. + + %a.anchor{ href: "#types", aria_hidden: "true" } + %h4#types Types of changes + + %ul + %li + %code Added + voor nieuwe functionaliteit. + %li + %code Changed + voor aanpassingen aan bestaande functionaliteit. + %li + %code Deprecated + voor functionaliteit die binnenkort komt te vervallen. + %li + %code Removed + voor functionaliteit die vanaf nu vervallen is. + %li + %code Fixed + voor bug fixes. + %li + %code Security + voor aanpassingen met betrekking tot veiligheid. + +.effort + + %h3#effort + %a.anchor{ href: "#effort", aria_hidden: "true" } + Hoe kan ik zo min mogelijk moeite stoppen in het bijhouden van een changelog? + + %p + Houd bovenin een Unreleased sectie bij met aanpassingen voor de komende release. + + %p Dit heeft twee doelen: + + %ul + %li + Mensen kunnen zien wat ze kunnen verwachten in aankomende releases. + %li + Als je een release doet kan je eenvoudig de Unreleased sectie + aanpassen naar een nieuwe release sectie. + +.bad-practices + %h3#bad-practices + %a.anchor{ href: "#bad-practices", aria_hidden: "true" } + Kan een changelog slecht zijn? + + %p Ja. Hier een paar manieren waarop je een changelog behoorlijk onbruikbaar kan maken. + + %h4#log-diffs + %a.anchor{ href: "#log-diffs", aria_hidden: "true" } + Commit log diffs + + %p + Commit log diffs gebruiken als een changelog is een slecht idee: + ze staan vol met ruis. Denk bijvoorbeeld aan merge commits, commits met + onduidelijke titels, documentatie aanpassingen etc. + + %p + Het doel van een commit bericht is om één enkele stap in de evolutie van de + code te beschrijven. XXXXXXXXXXXXX + + %p + Het doel van een changelog is om noemenswaardige aanpassingen te documenteren, + vaak over meerdere commits, en om deze duidelijk naar de eindgebruiker te communiceren. + + %h4#ignoring-deprecations + %a.anchor{ href: "#ignoring-deprecations", aria_hidden: "true" } + 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. + + %p + If you do nothing else, list deprecations, removals, and any + breaking changes in your changelog. + + + %h4#confusing-dates + %a.anchor{ href: "#confusing-dates", aria_hidden: "true" } + Confusing Dates + + %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 + 2017-07-17 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. + + %aside + There’s more. Help me collect these antipatterns by + = link_to "opening an issue", issues + or a pull request. + +.frequently-asked-questions + %h3#frequently-asked-questions + %a.anchor{ href: "#frequently-asked-questions", aria_hidden: "true" } + Frequently Asked Questions + + %h4#standard + %a.anchor{ href: "#standard", aria_hidden: "true" } + Is there a standard 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. + + %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. + + %p + Healthy criticism, discussion and suggestions for improvements + = link_to "are welcome.", issues + + + %h4#filename + %a.anchor{ href: "#filename", aria_hidden: "true" } + What should the changelog file be named? + + %p + Call it CHANGELOG.md. Some projects use + HISTORY, NEWS or RELEASES. + + %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? + + %h4#github-releases + %a.anchor{ href: "#github-releases", aria_hidden: "true" } + What about 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 v1.0.0) + into rich release notes by manually adding release notes or it can + pull annotated git tag messages and turn them into notes. + + %p + GitHub Releases create a non-portable changelog that can only be + displayed to users within the context of GitHub. It's possible to + make them look very much like the Keep a Changelog format, but it + tends to be a bit more involved. + + %p + The current version of GitHub releases is also arguably not very + discoverable by end-users, unlike the typical uppercase files + (README, CONTRIBUTING, etc.). Another + minor issue is that the interface doesn't currently offer links to + commit logs between each release. + + %h4#automatic + %a.anchor{ href: "#automatic", aria_hidden: "true" } + Can changelogs be automatically parsed? + + %p + It’s difficult, because people follow wildly different formats and + file names. + + %p + #{link_to "Vandamme", vandamme} is a Ruby gem created by the + #{link_to "Gemnasium", gemnasium} team and which parses many (but + not all) open source project changelogs. + + + %h4#yanked + %a.anchor{ href: "#yanked", aria_hidden: "true" } + What about yanked releases? + + %p + Yanked releases are versions that had to be pulled because of a + serious bug or security issue. Often these versions don't even + appear in change logs. They should. This is how you should display + them: + + %p ## 0.0.5 - 2014-12-13 [YANKED] + + %p + The [YANKED] tag is loud for a reason. It's important + for people to notice it. Since it's surrounded by brackets it's also + easier to parse programmatically. + + + %h4#rewrite + %a.anchor{ href: "#rewrite", aria_hidden: "true" } + Should you ever rewrite a changelog? + + %p + Sure. There are always good reasons to improve a changelog. I + regularly open pull requests to add missing releases to open source + projects with unmaintained changelogs. + + %p + It's also possible you may discover that you forgot to address a + breaking change in the notes for a version. It's obviously important + for you to update your changelog in this case. + + + %h4#contribute + %a.anchor{ href: "#contribute", aria_hidden: "true" } + How can I contribute? + + %p + This document is not the truth; it’s my carefully + considered opinion, along with information and examples I gathered. + + %p + This is because I want our community to reach a consensus. I believe + the discussion is as important as the end result. + + %p + So please #{link_to "pitch in", gh}. + +.press + %h3 Conversations + %p + I went on #{link_to "The Changelog podcast", thechangelog} + to talk about why maintainers and contributors should care about changelogs, + and also about the motivations behind this project. From b5a19ae22790a8ec7b2322e0e42f2a72258ee9db Mon Sep 17 00:00:00 2001 From: Jasper Krielaars Date: Fri, 22 Sep 2017 11:21:38 +0200 Subject: [PATCH 2/6] translated deprications, confusing dates, and 3 FAQ's --- source/nl/1.0.0/index.html.haml | 79 +++++++++++++++------------------ 1 file changed, 35 insertions(+), 44 deletions(-) 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 - 2017-07-17 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 2017-07-17 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 CHANGELOG.md. Some projects use - HISTORY, NEWS or RELEASES. + Noem het CHANGELOG.md. Sommige projecten gebruiken + HISTORY, NEWS of RELEASES. %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 v1.0.0) - 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 v1.0.0) + 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 From 338926b54ca56f963ef6428ade54fb50949162bc Mon Sep 17 00:00:00 2001 From: Jasper Krielaars Date: Thu, 26 Oct 2017 15:29:01 +0200 Subject: [PATCH 3/6] translated rest of FAQ's and conservations --- source/nl/1.0.0/index.html.haml | 78 ++++++++++++++++----------------- 1 file changed, 37 insertions(+), 41 deletions(-) diff --git a/source/nl/1.0.0/index.html.haml b/source/nl/1.0.0/index.html.haml index 6cd83b0..65c8da1 100644 --- a/source/nl/1.0.0/index.html.haml +++ b/source/nl/1.0.0/index.html.haml @@ -221,83 +221,79 @@ version: 1.0.0 door geannoteerde git tag berichten te gebruiken om release notes te genereren. %p - GitHub Releases create a non-portable changelog that can only be - displayed to users within the context of GitHub. It's possible to - make them look very much like the Keep a Changelog format, but it - tends to be a bit more involved. + GitHub Releases maken changelog wat alleen getoond kan worden aan gebruikers + binnen de context van GitHub. Het is mogelijk om deze dicht bij het format + te krijgen wat wij hier promoten, maar er zal iets meer werk voor nodig zijn. %p - The current version of GitHub releases is also arguably not very - discoverable by end-users, unlike the typical uppercase files - (README, CONTRIBUTING, etc.). Another - minor issue is that the interface doesn't currently offer links to - commit logs between each release. + De huidige versie van GitHub releases is naar mijn mening niet + echt goed vindbaar voor gebruikers, in tegenstelling tot de typische + bestanden die in een naam in hoofdletters hebben + (README, CONTRIBUTING, etc.). + Een ander knelpunt is dat de interface geen links toestaat naar + commit logs van elke release. %h4#automatic %a.anchor{ href: "#automatic", aria_hidden: "true" } - Can changelogs be automatically parsed? + Kunnen changelogs automatisch geparsed worden? %p - It’s difficult, because people follow wildly different formats and - file names. + Dat is lasig, mensen gebruiken immers veel verschillende formats en bestandsnamen. %p - #{link_to "Vandamme", vandamme} is a Ruby gem created by the - #{link_to "Gemnasium", gemnasium} team and which parses many (but - not all) open source project changelogs. + #{link_to "Vandamme", vandamme} is een Ruby gem van het + #{link_to "Gemnasium", gemnasium} team wat de changelogs van veel (maar niet alle) + open source projecten kan parsen. %h4#yanked %a.anchor{ href: "#yanked", aria_hidden: "true" } - What about yanked releases? + Wat doen we met teruggetrokken (yanked) releases? %p - Yanked releases are versions that had to be pulled because of a - serious bug or security issue. Often these versions don't even - appear in change logs. They should. This is how you should display - them: + Teruggetrokken releases zijn versies die teruggetrokken zijn als gevolg + van een serieuze bug of beveiligings probleem. Vaak zijn ze niet eens te zien in + de changelogs. Dat zou wel moeten. Zo zou je een teruggetrokken release moeten tonen: %p ## 0.0.5 - 2014-12-13 [YANKED] %p - The [YANKED] tag is loud for a reason. It's important - for people to notice it. Since it's surrounded by brackets it's also - easier to parse programmatically. + De [YANKED] tag is in hoofdletters voor een reden. Het is belanrijk + dat mensen dit zien. Omdat het tussen blokhaken genoteerd is, is het ook makkelijker + automatisch te parsen. %h4#rewrite %a.anchor{ href: "#rewrite", aria_hidden: "true" } - Should you ever rewrite a changelog? + Mag je een changelog aanpassen/herschrijven? %p - Sure. There are always good reasons to improve a changelog. I - regularly open pull requests to add missing releases to open source - projects with unmaintained changelogs. + Natuurlijk. Er zijn goede redenen om een changelog te verbeteren. + Ik open regelmatig een pull request om missende releases toe te + voegen aan open source projecten met een slecht onderhouden changelog. %p - It's also possible you may discover that you forgot to address a - breaking change in the notes for a version. It's obviously important - for you to update your changelog in this case. - + Het kan ook zo zijn dat je ontdekt dat je een belanrijke aanpassing niet + vermeld hebt in je changelog. Het is dan natuurlijk zaak om dit alsnog + in je changelog te vermelden. %h4#contribute %a.anchor{ href: "#contribute", aria_hidden: "true" } - How can I contribute? + Hoe kan ik bijdragen? %p - This document is not the truth; it’s my carefully - considered opinion, along with information and examples I gathered. + Dit document is niet de waarheid#{link_to "pitch in", gh}. + Dus #{link_to "alle hulp is welkom", gh}. .press - %h3 Conversations + %h3 Conversaties %p - I went on #{link_to "The Changelog podcast", thechangelog} - to talk about why maintainers and contributors should care about changelogs, - and also about the motivations behind this project. + Ik was te gast bij #{link_to "The Changelog podcast", thechangelog} om te praten over + waarom een changelog belanrijk zou moeten zijn voor programmeurs, en over mijn motivatie achter dit project. From 911acf7b0006b27b889766dbff2240b4b14266fa Mon Sep 17 00:00:00 2001 From: Jasper Krielaars Date: Thu, 26 Oct 2017 15:46:48 +0200 Subject: [PATCH 4/6] fixed todo's --- source/nl/1.0.0/index.html.haml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/source/nl/1.0.0/index.html.haml b/source/nl/1.0.0/index.html.haml index 65c8da1..5e0bb05 100644 --- a/source/nl/1.0.0/index.html.haml +++ b/source/nl/1.0.0/index.html.haml @@ -66,7 +66,7 @@ version: 1.0.0 %li Changelogs zijn voor mensen, niet voor machines. %li - Er zou een XXX moeten zijn voor elke versie. + Er zou een vermelding moeten zijn voor elke versie. There should be an entry for every single version. %li Aanpassingen van het zelfde type moeten gegroepeerd worden. @@ -138,7 +138,7 @@ version: 1.0.0 %p Het doel van een commit bericht is om één enkele stap in de evolutie van de - code te beschrijven. XXXXXXXXXXXXX + code te beschrijven. %p Het doel van een changelog is om noemenswaardige aanpassingen te documenteren, @@ -282,7 +282,7 @@ version: 1.0.0 Hoe kan ik bijdragen? %p - Dit document is niet de waarheidwaarheid; het is mijn weloverwogen mening, samen met wat informatie en voorbeelden die ik verzameld heb. %p From 59fa8be48d5b89e7729f330ab5367e6b882430f0 Mon Sep 17 00:00:00 2001 From: Jasper Krielaars Date: Thu, 25 Jan 2018 08:39:40 +0100 Subject: [PATCH 5/6] Fixed typos and added suggestions from @vanhooferwin and @ericcornelissen --- source/nl/1.0.0/index.html.haml | 58 ++++++++++++++++----------------- 1 file changed, 29 insertions(+), 29 deletions(-) diff --git a/source/nl/1.0.0/index.html.haml b/source/nl/1.0.0/index.html.haml index 5e0bb05..990fae4 100644 --- a/source/nl/1.0.0/index.html.haml +++ b/source/nl/1.0.0/index.html.haml @@ -42,15 +42,15 @@ version: 1.0.0 %p Om het makkelijker te maken voor gebruikers en programmeurs om precies te zien welke - noemenswaardige aanassingen er gedaan zijn tussen elke release (of versie) van het project. + noemenswaardige aanpassingen er gedaan zijn tussen elke release (of versie) van het project. %h3#who %a.anchor{ href: "#who", aria_hidden: "true" } Wie heeft een changelog nodig? %p - Mensen hebben dat nodig. Of het nou consumenten of developers zijn, eindgebruikers van - software zijn mensen die er om gevenwat er in de software zit die ze gebruiken. + Mensen hebben het nodig. Of het nu consumenten of ontwikkelaars zijn, eindgebruikers van + software zijn mensen die er om geven wat er in de software zit die ze gebruiken. Als de software veranderd, wil men weten wat en hoe. .good-practices @@ -71,7 +71,7 @@ version: 1.0.0 %li Aanpassingen van het zelfde type moeten gegroepeerd worden. %li - Versies en secties souden linkbaar moeten zijn. + Versies en secties zouden linkbaar moeten zijn. %li De laatste versie staat bovenaan. %li @@ -106,7 +106,7 @@ version: 1.0.0 %h3#effort %a.anchor{ href: "#effort", aria_hidden: "true" } - Hoe kan ik zo min mogelijk moeite stoppen in het bijhouden van een changelog? + Hoe kan ik, met zo min mogelijk moeite, een changelog bij houden? %p Houd bovenin een Unreleased sectie bij met aanpassingen voor de komende release. @@ -115,7 +115,7 @@ version: 1.0.0 %ul %li - Mensen kunnen zien wat ze kunnen verwachten in aankomende releases. + Mensen kunnen zien wat te verwachten in de aankomende release. %li Als je een release doet kan je eenvoudig de Unreleased sectie aanpassen naar een nieuwe release sectie. @@ -152,7 +152,7 @@ version: 1.0.0 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 + vervolgens de deprications weg te halen, en vervolgens de upgrade kunnen doen naar de versie waar de deprications removals zijn geworden. %p @@ -185,13 +185,13 @@ version: 1.0.0 Is er een standaard changelog template? %p - Niet echt. Er is de GNU changelog style guide, en de twee paragrafen GNU NEWS bestand "richtlijnen". + Niet echt. Er is de GNU changelog style guide, en het twee paragrafen lange GNU NEWS bestand "richtlijnen". Beiden zijn niet volledig genoeg. %p 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. + te creëren. Dit op basis van "good practices" uit de open source wereld. %p Opbouwende kritiek, discussie en suggesties voor verbetering @@ -216,7 +216,7 @@ version: 1.0.0 %p Het is een goed initiatief. #{link_to "Releases", ghr} kan gebruikt worden - om simpele git tags (bijvoorbeeld een tag met naam v1.0.0) + om simpele git tags (bijvoorbeeld een tag met de naam v1.0.0) 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. @@ -258,7 +258,7 @@ version: 1.0.0 %p ## 0.0.5 - 2014-12-13 [YANKED] %p - De [YANKED] tag is in hoofdletters voor een reden. Het is belanrijk + De [YANKED] tag is in hoofdletters voor een reden. Het is belangrijk dat mensen dit zien. Omdat het tussen blokhaken genoteerd is, is het ook makkelijker automatisch te parsen. @@ -267,27 +267,27 @@ version: 1.0.0 %a.anchor{ href: "#rewrite", aria_hidden: "true" } Mag je een changelog aanpassen/herschrijven? - %p - Natuurlijk. Er zijn goede redenen om een changelog te verbeteren. - Ik open regelmatig een pull request om missende releases toe te - voegen aan open source projecten met een slecht onderhouden changelog. + %p + Natuurlijk. Er zijn goede redenen om een changelog te verbeteren. + Ik open regelmatig een pull request om missende releases toe te + voegen aan open source projecten met een slecht onderhouden changelog. - %p - Het kan ook zo zijn dat je ontdekt dat je een belanrijke aanpassing niet - vermeld hebt in je changelog. Het is dan natuurlijk zaak om dit alsnog - in je changelog te vermelden. + %p + Het kan ook zo zijn dat je ontdekt dat je een belanrijke aanpassing niet + vermeld hebt in je changelog. Het is dan natuurlijk zaak om dit alsnog + in je changelog te vermelden. - %h4#contribute - %a.anchor{ href: "#contribute", aria_hidden: "true" } - Hoe kan ik bijdragen? + %h4#contribute + %a.anchor{ href: "#contribute", aria_hidden: "true" } + Hoe kan ik bijdragen? - %p - Dit document is niet de waarheid; het is mijn - weloverwogen mening, samen met wat informatie en voorbeelden die ik verzameld heb. + %p + Dit document is niet de waarheid; het is mijn + weloverwogen mening, samen met wat informatie en voorbeelden die ik verzameld heb. - %p - Dit heb ik gedaan omdat ik wil dat de programmeer gemeenschap een consensus bereikt. - Ik denk dat de discussie net zo belanrijk is als het eindresultaat. + %p + Dit heb ik gedaan omdat ik wil dat de programmeer gemeenschap een consensus bereikt. + Ik denk dat de discussie net zo belanrijk is als het eindresultaat. %p Dus #{link_to "alle hulp is welkom", gh}. @@ -296,4 +296,4 @@ version: 1.0.0 %h3 Conversaties %p Ik was te gast bij #{link_to "The Changelog podcast", thechangelog} om te praten over - waarom een changelog belanrijk zou moeten zijn voor programmeurs, en over mijn motivatie achter dit project. + waarom een changelog belanrijk is programmeurs, en over mijn motivatie achter dit project. From 8d3a0071981311f7fd876d7a8adafce6f4f1fae9 Mon Sep 17 00:00:00 2001 From: Jasper Krielaars Date: Thu, 25 Jan 2018 17:14:50 +0100 Subject: [PATCH 6/6] Fixed typo's --- source/nl/1.0.0/index.html.haml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/source/nl/1.0.0/index.html.haml b/source/nl/1.0.0/index.html.haml index 990fae4..d42280e 100644 --- a/source/nl/1.0.0/index.html.haml +++ b/source/nl/1.0.0/index.html.haml @@ -207,7 +207,7 @@ version: 1.0.0 HISTORY, NEWS of RELEASES. %p - Je kan denken dat de bestandsnaam niet heel belanrijk is, + Je kan denken dat de bestandsnaam niet heel belangrijk is, maar waarom zou je het de eindgebruikers moeilijker maken om de changelog te vinden? %h4#github-releases @@ -273,7 +273,7 @@ version: 1.0.0 voegen aan open source projecten met een slecht onderhouden changelog. %p - Het kan ook zo zijn dat je ontdekt dat je een belanrijke aanpassing niet + Het kan ook zo zijn dat je ontdekt dat je een belangrijke aanpassing niet vermeld hebt in je changelog. Het is dan natuurlijk zaak om dit alsnog in je changelog te vermelden. @@ -287,7 +287,7 @@ version: 1.0.0 %p Dit heb ik gedaan omdat ik wil dat de programmeer gemeenschap een consensus bereikt. - Ik denk dat de discussie net zo belanrijk is als het eindresultaat. + Ik denk dat de discussie net zo belangrijk is als het eindresultaat. %p Dus #{link_to "alle hulp is welkom", gh}. @@ -296,4 +296,4 @@ version: 1.0.0 %h3 Conversaties %p Ik was te gast bij #{link_to "The Changelog podcast", thechangelog} om te praten over - waarom een changelog belanrijk is programmeurs, en over mijn motivatie achter dit project. + waarom een changelog belangrijk is programmeurs, en over mijn motivatie achter dit project.