From 97d503facbaea39a8f81c2b966d732229e0365e5 Mon Sep 17 00:00:00 2001 From: Frederik Spang Date: Tue, 10 Mar 2020 16:37:58 +0100 Subject: [PATCH] Add Danish (da) translations. (#297) --- CHANGELOG.md | 2 + config.rb | 4 + source/da/1.1.0/index.html.haml | 332 ++++++++++++++++++++++++++++++++ 3 files changed, 338 insertions(+) create mode 100644 source/da/1.1.0/index.html.haml 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.