From 0e74dd2491b8388a69b412c97887f329ebba2292 Mon Sep 17 00:00:00 2001 From: jkrielaars Date: Tue, 2 Feb 2021 20:31:16 +0100 Subject: [PATCH] Added the dutch translation of the "Inconsistent changes" section (#372) * Fixed foldout menu in Dutch translation * Added Dutch translation of inconsistent changes section --- .gitignore | 1 + CHANGELOG.md | 4 + source/nl/1.0.0/index.html.haml | 42 ++--- source/nl/1.1.0/index.html.haml | 312 ++++++++++++++++++++++++++++++++ 4 files changed, 338 insertions(+), 21 deletions(-) create mode 100644 source/nl/1.1.0/index.html.haml diff --git a/.gitignore b/.gitignore index ef485346..6da15333 100644 --- a/.gitignore +++ b/.gitignore @@ -5,3 +5,4 @@ /build /_site /.vs +/.idea diff --git a/CHANGELOG.md b/CHANGELOG.md index 3a3b4c2c..914c37df 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -6,6 +6,10 @@ The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/), and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html). ## [Unreleased] +### Added +- Added Dutch translation of +### Fixed +- Fixed foldouts in Dutch translation ## [1.1.0] - 2019-02-15 diff --git a/source/nl/1.0.0/index.html.haml b/source/nl/1.0.0/index.html.haml index c363c480..4bbdcfce 100644 --- a/source/nl/1.0.0/index.html.haml +++ b/source/nl/1.0.0/index.html.haml @@ -265,27 +265,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 - 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. - - %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 heb ik gedaan omdat ik wil dat de programmeer gemeenschap een consensus bereikt. - Ik denk dat de discussie net zo belangrijk is als het eindresultaat. + %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 belangrijke 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? + + %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 belangrijk is als het eindresultaat. %p Dus #{link_to "alle hulp is welkom", gh}. diff --git a/source/nl/1.1.0/index.html.haml b/source/nl/1.1.0/index.html.haml new file mode 100644 index 00000000..f5e1e26a --- /dev/null +++ b/source/nl/1.1.0/index.html.haml @@ -0,0 +1,312 @@ +--- +description: Keep a Changelog +title: Keep a Changelog +language: nl +version: 1.1.0 +--- + +- changelog = "https://github.com/olivierlacan/keep-a-changelog/blob/master/CHANGELOG.md" +- gh = "https://github.com/olivierlacan/keep-a-changelog" +- issues = "https://github.com/olivierlacan/keep-a-changelog/issues" +- semver = "https://semver.org/" +- shields = "https://shields.io/" +- thechangelog = "https://changelog.com/podcast/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 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 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 verandert, 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 vermelding moeten zijn voor elke versie. + %li + Aanpassingen van het zelfde type moeten gegroepeerd worden. + %li + Versies en secties zouden 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, met zo min mogelijk moeite, een changelog bij houden? + + %p + Houd bovenin een Unreleased sectie bij met aanpassingen voor de komende release. + + %p Dit heeft twee doelen: + + %ul + %li + 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. + +.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. + + %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 + 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 deprecations, + vervolgens de deprecations weg te halen, en vervolgens + de upgrade kunnen doen naar de versie waar de deprecations removals zijn geworden. + + %p + Geef altijd op zijn minst de deprecations, removals en changes met grote impact aan in je changelog. + + %h4#confusing-dates + %a.anchor{ href: "#confusing-dates", aria_hidden: "true" } + Verwarrende datums + + %p + Datum notaties verschillen van land tot land, en het is vaak moeilijk om + een notatie te vinden die makkelijk te lezen is en intuïtief 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. + + %h4#inconsistent-changes + %a.anchor{ href: "#inconsistent-changes", aria_hidden: "true" } + Inconsistente Aanpassingen + + %p + Een changelog waar slechts een aantal van de aanpassingen in vermeld staat + lan net zo gevaarlijk zijn als geen changelog hebben. + Sommige aanpassingen zullen te irrelevant zijn - bijvoorbeeld, het weghalen + van een overbodige spatie hieft niet altijd vermeld te worden - maar alle + belanrijke aanpassingen souden in het changelog vermeld moeten worden. + Door inconsistent te loggen kunnen gebruikers onterecht denken dat de changelog + de de complete bron van waarheid is. Dit zou wel zo moeten zijn. + "With great power comes great responsibility". Als je een changelog bij houd, + zorg er dan voor dat deze continue bijgehouden word. + + %aside + 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" } + Veel Gestelde Vragen + + %h4#standard + %a.anchor{ href: "#standard", aria_hidden: "true" } + Is er een standaard changelog template? + + %p + 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 "good practices" uit de open source wereld. + + %p + Opbouwende kritiek, discussie en suggesties voor verbetering + = link_to "zijn welkom.", issues + + + %h4#filename + %a.anchor{ href: "#filename", aria_hidden: "true" } + Wat zou de changelog bestandsnaam moeten zijn? + + %p + Noem het CHANGELOG.md. Sommige projecten gebruiken + HISTORY, NEWS of RELEASES. + + %p + 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 + %a.anchor{ href: "#github-releases", aria_hidden: "true" } + Wat denk je van GitHub Releases? + + %p + Het is een goed initiatief. #{link_to "Releases", ghr} kan gebruikt worden + 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. + + %p + 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 + 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" } + Kunnen changelogs automatisch geparsed worden? + + %p + Dat is lastig, mensen gebruiken immers veel verschillende formats en bestandsnamen. + + %p + #{link_to "Vandamme", vandamme} is een Ruby gem van het + Gemnasium team wat de changelogs van veel (maar niet alle) + open source projecten kan parsen. + + + %h4#yanked + %a.anchor{ href: "#yanked", aria_hidden: "true" } + Wat doen we met teruggetrokken (yanked) releases? + + %p + 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 + 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. + + + %h4#rewrite + %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 + 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. + + %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 heb ik gedaan omdat ik wil dat de programmeer gemeenschap een consensus bereikt. + Ik denk dat de discussie net zo belangrijk is als het eindresultaat. + + %p + Dus #{link_to "alle hulp is welkom", gh}. + +.press + %h3 Conversaties + %p + Ik was te gast bij #{link_to "The Changelog podcast", thechangelog} om te praten over + waarom een changelog belangrijk is programmeurs, en over mijn motivatie achter dit project.