diff --git a/CHANGELOG.md b/CHANGELOG.md
index d9862a9..a8256e9 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -6,6 +6,8 @@ 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
+- Danish translation from [@frederikspang](https://github.com/frederikspang).
## [1.1.0] - 2019-02-15
diff --git a/config.rb b/config.rb
index a927725..79f614d 100644
--- a/config.rb
+++ b/config.rb
@@ -18,6 +18,10 @@ $languages = {
"cs" => {
name: "Čeština"
},
+ "da" => {
+ name: "Dansk",
+ new: "En ny version er tilgængelig"
+ },
"de" => {
name: "Deutsch",
notice: "Die neuste version (#{$last_version}) ist noch nicht auf Deutsch
diff --git a/source/da/1.1.0/index.html.haml b/source/da/1.1.0/index.html.haml
new file mode 100644
index 0000000..3664b04
--- /dev/null
+++ b/source/da/1.1.0/index.html.haml
@@ -0,0 +1,332 @@
+---
+description: Hold en changelog
+title: Hold en changelog
+language: da
+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/"
+- gnustyle = "https://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html#Style-of-Change-Logs"
+- gnunews = "https://www.gnu.org/prep/standards/html_node/NEWS-File.html#NEWS-File"
+
+.header
+ .title
+ %h1 Hold en changelog
+ %h2 Du skal ikke lade dine venner smide git logs i changelogs.
+
+ = link_to changelog do
+ Version
+ %strong= current_page.metadata[:page][:version]
+
+ %pre.changelog= File.read("CHANGELOG.md")
+
+.answers
+ %h3#what
+ %a.anchor{ href: "#what", aria_hidden: "true" }
+ Hvad er en changelog?
+
+ %p
+ En changelog er en fil, der indeholder en organiseret, kronologisk
+ sorteret liste af bemærkelsesværdige ændringer for hver version
+ af et projekt.
+
+ %h3#why
+ %a.anchor{ href: "#why", aria_hidden: "true" }
+ Hvorfor have en changelog?
+
+ %p
+ For at gøre det nemmere for brugere og bidragsydere at se præcist
+ hvilke bemærkelsesværdige ændringer, der er lavet mellem hver
+ udgivelse eller version af et projekt.
+
+ %h3#who
+ %a.anchor{ href: "#who", aria_hidden: "true" }
+ Hvem skal bruge en changelog?
+
+ %p
+ Det skal folk. Om det er forbrugere eller udviklere, er slutbrugere
+ mennesker, der bekymrer sig om, hvad der er i et stykke software. Når
+ softwaren ændrer sig, vil folk gerne vide hvad, og hvordan.
+
+.good-practices
+ %h3#how
+ %a.anchor{ href: "#how", aria_hidden: "true" }
+ Hvordan laver jeg en god changelog?
+
+ %h4#principles
+ %a.anchor{ href: "#principles", aria_hidden: "true" }
+ Retningslinjer
+
+ %ul
+ %li
+ Changelogs er til for mennesker, ikke maskiner.
+ %li
+ Der skal være et indlæg for hver eneste version.
+ %li
+ Ens typer af ændringer skal grupperes.
+ %li
+ Versioner og sektioner skal være link-bare.
+ %li
+ Den seneste version står først.
+ %li
+ Udgivelsesdatoen for hver version vises.
+ %li
+ Nævn hvorvidt du følger #{link_to "Semantisk Versionering", semver}.
+
+ %a.anchor{ href: "#types", aria_hidden: "true" }
+ %h4#types Ændringstyper
+
+ %ul
+ %li
+ %code Tilføjet (Added)
+ til nye funktioner.
+ %li
+ %code Ændret (Dhanged)
+ til rettelser i eksisterende funktionalitet.
+ %li
+ %code Udfaset (Deprecated)
+ til funktioner, der fjernes snart.
+ %li
+ %code Fjernet (Removed)
+ til fjernede funktioner.
+ %li
+ %code Rettet (Fixed)
+ til fejlrettelser.
+ %li
+ %code Sikkerhed (Security)
+ i tilfælde af sårbarheder.
+
+.effort
+
+ %h3#effort
+ %a.anchor{ href: "#effort", aria_hidden: "true" }
+ Hvordan kan jeg reducere indsatsen ved at opretholde en changelog?
+
+ %p
+ Hav en Unreleased sektion i toppen til kommende
+ rettelser.
+
+ %p Dette tjener to formål:
+
+ %ul
+ %li
+ Folk kan se, hvilke rettelser de kan forvente i den kommende
+ udgivelse
+ %li
+ Ved udgivelsen kan du flytte Unreleased sektionens
+ rettelser ind i en ny versionssektion.
+
+.bad-practices
+ %h3#bad-practices
+ %a.anchor{ href: "#bad-practices", aria_hidden: "true" }
+ Kan changelogs være dårlige?
+
+ %p Ja. Her er et par måder, de kan være mindre brugbare.
+
+ %h4#log-diffs
+ %a.anchor{ href: "#log-diffs", aria_hidden: "true" }
+ Commit log diffs
+
+ %p
+ At bruge commit log differenser som changelog er en dårlig idé:
+ De er fyldt med støj. Ting som merge-commits, commits med obskure titler,
+ dokumentationsrettelser osv.
+
+ %p
+ Formålet med et commit er at dokumentere et trin i udviklingen af
+ kildekoden. Nogle projekter rydder op i deres commits, andre gør
+ ikke.
+
+ %p
+ Formålet med en changelog-indlæg er at dokumentere de bemærkelsesværdige
+ forskelle, ofte fordelt over flere commits, for at formidle dem klart
+ til slutbrugerene.
+
+ %h4#ignoring-deprecations
+ %a.anchor{ href: "#ignoring-deprecations", aria_hidden: "true" }
+ At ignorere udfasninger
+
+ %p
+ Når folk opgraderer fra én version til en anden, skal det være helt
+ tydeligt, hvorvidt noget vil gå i stykker. Det skal være muligt
+ at opgradere til en version, der opsummerer udfasninger, fjerner
+ gamle udfasniner, og opgradere til dén version, hvor udfasningerne
+ bliver til oprydninger.
+
+ %p
+ Hvis du ikke gør andet, så notér udfasninger, fjernede funktioner
+ og andre ødelæggende ændringer.
+
+
+ %h4#confusing-dates
+ %a.anchor{ href: "#confusing-dates", aria_hidden: "true" }
+ Forvirrende datoer
+
+ %p
+ Regionale dataformater er varierende i hele verden, og det er ofte
+ besværligt at finde et læsbart datoformat, der føles intuitivt for alle
+ Fordelen ved datoer formatteret som 2017-07-17 er at de
+ følger rækkefølgen for største til mindste enhed: år, måned og dag.
+ Dette format overlapper heller ikke på en tvetydig måde med andre
+ datoformater, der ombytter måneden og daten. Af disse årsager, og
+ det faktum at dette datoformat er en #{link_to "ISO standard", iso},
+ er dette det anbefalede datoformat for changelog-indlæg.
+
+ %h4#inconsistent-changes
+ %a.anchor{ href: "#inconsistent-changes", aria_hidden: "true" }
+ Ukonsistente rettelser
+
+ %p
+ En changelog, der kun nævner nogle af ændringerne, kan være lige så
+ farlig som ikke at have en changelog. Mens mange af ændringerne
+ måske ikke er relevante - for eksempel er det ikke være nødvendigt at
+ notere, at vi har fjernet et enkelt mellemrum - bør væsentlige
+ ændringer være nævnt i changeloggen. Ved inkonsekvent at anvende
+ ændringer, kan dine brugere fejlagtigt tro, at changelog er den
+ eneste kilde til sandhed. Det bør den være. Med store
+ magtbeføjelser følger store forpligtigelser. At have en god changelog
+ er at have en konsekvent opdateret changelog.
+
+ %aside
+ Der er mere. Hjælp mig med at samle disse fælder ved at
+ = link_to "åbne et issue", issues
+ eller et pull-request.
+
+.frequently-asked-questions
+ %h3#frequently-asked-questions
+ %a.anchor{ href: "#frequently-asked-questions", aria_hidden: "true" }
+ Ofte stillede spørgsmål
+
+ %h4#standard
+ %a.anchor{ href: "#standard", aria_hidden: "true" }
+ Er der et standard changelog-format?
+
+ %p
+ Ikke rigtig. Der er #{link_to "GNU changelog style guide", gnustyle},
+ eller #{link_to "two-paragraph-long GNU NEWS file", gnunews}. De
+ er begge utilstrækkelige eller uhensigtsmæssige.
+
+ %p
+ Dette projekt sigter efter at være
+ = link_to "en bedre changelog konvention.", changelog
+ Det kommer af at observere god praksis i opensource-verdenen
+ og samle disse.
+
+ %p
+ Konstruktiv kritik diskussion og forbedringsforslag
+ = link_to "er velkomne.", issues
+
+
+ %h4#filename
+ %a.anchor{ href: "#filename", aria_hidden: "true" }
+ Hvad skal changelog-filen hedde?
+
+ %p
+ Kald den CHANGELOG.md. Nogle projekter bruger
+ HISTORY, NEWS eller RELEASES.
+
+ %p
+ Selvom det er nemt at mene, at navnet på changelog-filen er
+ irrelevant, hvorfor så gøre det sværere for dine slugbrugere
+ at finde bemærkelsesværdige ændringer?
+
+
+ %h4#github-releases
+ %a.anchor{ href: "#github-releases", aria_hidden: "true" }
+ Hvad med GitHub Releases?
+
+ %p
+ Det er et godt initiativ. #{link_to "Releases", ghr} kan bruges
+ til at gøre simple git tags (for eksempel, et tag v1.0.0)
+ til fyldige udgivelsesnoter ved manuelt at tilføje noter til disse
+ eller bruge en annoteret git-tag-besked som udgivelsesnoter.
+
+ %p
+ GitHub Releases laver en ikke-flytbar changelog, der kun kan vises
+ til bruger i konteksten af GitHub. Det er muligt at få dem til at
+ ligne Hold en changelog-formatet, men det har en tendens til at
+ være lidt mere kompliceret.
+
+ %p
+ Den nuværende version af GitHub releases er, diskutérbart,
+ ikke særligt synlig for slutbrugere, ikke lig de typiske
+ kapitaliserede filer (README,
+ CONTRIBUTING, osv.). Et andet mindre problem, er
+ at interfacet ikke tilbyder links til commit logs mellem hvert
+ release.
+
+ %h4#automatic
+ %a.anchor{ href: "#automatic", aria_hidden: "true" }
+ Kan changelogs læses og fortolkes automatisk?
+
+ %p
+ Det er besværligt, fordi folk følger vidt forskellige formater
+ og filnavne.
+
+ %p
+ #{link_to "Vandamme", vandamme} er en Ruby gem lavet af
+ holdet bag Gemnasium, som læser og fortolker mange (men ikke
+ alle) open source projekters changelogs.
+
+ %h4#yanked
+ %a.anchor{ href: "#yanked", aria_hidden: "true" }
+ Hvad med tilbagetrukkede udgivelser?
+
+ %p
+ Tilbagetrukkede udgivelser er versioner, der er blevet trukket
+ tilbage på grund af en seriøs fejl eller sikkerhedsbrist. Ofte
+ vises disse versioner slet ikke i changelogs. Det bør de. Dette
+ er hvordan du bør vise dem:
+
+ %p ## 0.0.5 - 2014-12-13 [YANKED]
+
+ %p
+ Notationen [YANKED], er højlydt af en årsag: Det er
+ vigtig information for folk. Siden den er pakket ind i klammer, er
+ den nemmere at fortolke og læse systematiseret.
+
+
+ %h4#rewrite
+ %a.anchor{ href: "#rewrite", aria_hidden: "true" }
+ Bør man nogensinde omskrive en changelog?
+
+ %p
+ Klart! Der er altid gode grunde til at forbedre en changelog.
+ Jeg åbner jævnligt pull-requests, der tilføjer manglende releases
+ til open source projekter uden en vedligeholdt changelog.
+
+ %p
+ Det er også muligt, at du vil opdage at du har glemt at addressere
+ en ødelæggende rettelse i noterne for en version. Det er selvfølgelig
+ vigtigt at du opdaterer en changelog i disse tilfælde.
+
+
+ %h4#contribute
+ %a.anchor{ href: "#contribute", aria_hidden: "true" }
+ Hvordan kan jeg hjælpe til?
+
+ %p
+ Dette dokument er ikke sandheden; det er min
+ velovervejede mening sammen med information og eksempler jeg har
+ samlet.
+
+ %p
+ Det er fordi, jeg gerne vil have at vores fællesskab når en konsensus.
+ Jeg mener at diskussionen er lige så vigtig som slutresultatet.
+ %p
+ Så, #{link_to "vær med!", gh}
+
+.press
+ %h3 Samtaler
+ %p
+ Jeg var med i #{link_to "The Changelog podcast", thechangelog} for
+ at snakke om, hvorfor vedligeholdere og bidragsydere bør bekymre sig
+ om changelogs og også om motivationen bag dette projekt.