mirror of
https://github.com/olivierlacan/keep-a-changelog.git
synced 2025-07-29 08:44:16 +02:00
Add Danish (da) translations. (#297)
This commit is contained in:
Frederik Spang
GitHub
parent
74e6f68643
commit
97d503facb
@ -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
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
332
source/da/1.1.0/index.html.haml
Normal file
332
source/da/1.1.0/index.html.haml
Normal file
@ -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 <em>for mennesker</em>, 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 <code>Unreleased</code> 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 <code>Unreleased</code> 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 <code>2017-07-17</code> 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 <code>CHANGELOG.md</code>. Nogle projekter bruger
|
||||
<code>HISTORY</code>, <code>NEWS</code> eller <code>RELEASES</code>.
|
||||
|
||||
%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 <code>v1.0.0</code>)
|
||||
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 (<code>README</code>,
|
||||
<code>CONTRIBUTING</code>, 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 <code>## 0.0.5 - 2014-12-13 [YANKED]</code>
|
||||
|
||||
%p
|
||||
Notationen <code>[YANKED]</code>, 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 <strong>sandheden</strong>; 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å, <strong>#{link_to "vær med!", gh}</strong>
|
||||
|
||||
.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.
|
||||
Loading…
x
Reference in New Issue
Block a user