diff --git a/CHANGELOG.md b/CHANGELOG.md index b4e2b6b..463d923 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -6,6 +6,7 @@ This project adheres to [Semantic Versioning](http://semver.org/). ### Added - zh-CN and zh-TW translations from @tianshuo. - de translation from @mpbzh. +- sv translation from @magol ## [0.3.0] - 2015-12-03 ### Added diff --git a/config.rb b/config.rb index 01d6293..1ecca8a 100644 --- a/config.rb +++ b/config.rb @@ -11,7 +11,8 @@ $languages = { "pt-BR" => "Brazilian Portugese", ru: "Pyccкий", "zh-CN" => "简体中文", - "zh-TW" => " 繁體中文" + "zh-TW" => " 繁體中文", + "sv" => "Svenska" } activate :i18n, diff --git a/source/sv/0.3.0/index.html.haml b/source/sv/0.3.0/index.html.haml new file mode 100644 index 0000000..f631ab2 --- /dev/null +++ b/source/sv/0.3.0/index.html.haml @@ -0,0 +1,187 @@ +--- +description: Håll en ändringslogg +title: Håll en ändringslogg +language: sv +version: 0.3.0 +--- + +:markdown + # Håll en CHANGELOG + + ## Låt inte dina vänner slänga in en git logs i CHANGELOG™ + + Version **#{current_page.metadata[:page][:version]}** + + ### Vad är en ändringslogg? + En ändringslogg är en fil innehållandes en sammanfattad, kronologiskt ordnad + lista över ändringar för varje version av ett projekt. + +%pre.changelog= File.read("CHANGELOG.md") + +:markdown + ### Vad är meningen med en ändringslogg? + För att göra det enkelt för användare och medarbetare att se exakt vilka + viktiga ändringar som har gjort mellan varje utgåva (eller version) av projektet. + + ### Varför ska jag bry mig? + Därför att mjukvaruverktyg är för människor. Om du inte bryr dig, varför + bidrar du till öppen källkod? Visst finns det väl någon del i din vackra + hjärna som bryr sig. + + Jag [pratade med Adam Stacoviak och Jerod Santo på The Changelog][thechangelog] + (passande, eller hur?) podcast om varför ansvariga och bidragsgivare bör bry sig, + och motiveringen bakom detta projekt. + Om du kan avvara lite tid (1:06), rekommenderar jag att lyssna på det. + + ### Vad gör en bra ändringslogg? + Jag är glad att du frågade. + + En bra ändringslogg håller sig till dessa principer: + + - Den är skapad för människor, inte maskiner, så läsbarhet är avgörande. + - Lätt att länka till valfri sektion (därav Markdown framför klartext). + - En undersektion per version. + - Lista utgåvor i omvänd kronologisk ordning (nyast högst upp). + - Skriv alla datum på formatet `YYYY-MM-DD` + (exempel: `2012-06-02` för 2:a juni 2012). Det är internationellt, + [förnuftigt](http://xkcd.com/1179/) och språkoberoende. + - Ange uttryckligen att projektet följer [Semantisk versionshantering][SemVer]. + - Varje version bör: + - Ange datum då utgåvan släptes på formatet angivet ovan. + - Gruppera ändringar för att beskriva deras inverkan på projektet enligt följande: + - `Added` för nya funktioner. + - `Changed` för ändringar på existerande funktionalitet. + - `Deprecated` för tidigare stabila funktioner som tas bort i nästa utgåva. + - `Removed` för funktioner tidigare markerade som `deprecated` som tas bort i denna version. + - `Fixed` för buggfixar. + - `Security` för att uppmana användare att uppgradera vid fall av sårbarheter. + + ### Hur kan jag minimera den insats som krävs? + Ha alltid en sektion kallas `"Unreleased"` högst upp för att hålla reda på + alla ändringar. + + Detta tjänar två syften: + + - Folk kan se vilka ändringar som kan förväntas i kommande utgåvor + - Vid lansering behöver du bara ändra `"Unreleased"` till versionsnumret + och lägga till en ny `"Unreleased"` högst upp. + + ### Vad får änglarna att gråta? + Okej...låt oss gå genom det. + + - **Dumpa ut en diff från commit-loggen.** Gör helt enkelt inte så, du hjälper ingen. + - **Inte betona `deprecations`.** När folk uppgraderar från en version till + en annan ska det vara smärtsamt uppenbart om något förväntas gå sönder. + - **Datum i region-specifikt format.** I USA lägger folk månaden föst + ("06-02-2012" för 2:a juni 2012, vilket bara är *konstigt*), medan många + andra runt om i världen skriver "2 June 2012" men uttala det annorlunda. + "2012-06-02" fungerar logiskt från största till minsta, inte överlappar på ett + tvetydligt sätt med andra datumformat, och det är en + [ISO-standard](http://www.iso.org/iso/home/standards/iso8601.htm). Dessutom + är det rekommenderat datumformat för ändringsloggar. + + + Det finns mer. Hjälp mig att samla tårarna från änglarna genom att + [öppna en issue][issues] + eller en pull-förfrågan. + + ### Finns det ett standardformat på ändringsloggar? + Tyvärr inte. Men lugn. Jag vet att du frustrerad kommer att rusa iväg för att hitta + den där länken till GUS:s format för ändringsloggar, eller den två stycken långa + GNU NEWS-filen med "guideline". Stilguiden från GNU är en bra start, men den är + tyvärr allt för naiv. Det är inget fel med att vara naiv, men när människor + behöver vägledning är det inte speciellt hjälpsamt. Speciellt när det är många + olika situationer och specialfall att hantera. + + Detta projekt [innehåller vad jag hoppas kommer att bli en bättre filkonvention + för CHANGELOG][CHANGELOG]. Jag tror inte att status quo är tillräckligt bra, + och jag tror att vi tillsammans kan komma fram till en bättre konvention + om vi försöker att plocka ut bra erfarenheter från riktiga mjukvaruprojekt. + Titta runt och kom ihåg att [diskussioner och förbättringsförslag är välkomna][issues]! + + ### Vad bör filen med ändringsloggen heta? + Tja, om du inte kan lista ut det från exemplen ovan är `CHANGELOG.md` + den bästa konvention hittills. + + En del projekt använder också `HISTORY.txt`, `HISTORY.md`, `History.md`, `NEWS.txt`, + `NEWS.md`, `News.txt`, `RELEASES.txt`, `RELEASE.md`, `releases.md`, etc. + + Det är en verklig röra. Alla dessa namn gör det bara svårare för människor att hitta. + + ### Varför kan folk inte bara använda en diff från `git log`? + Eftersom logg-diffar av naturen är fulla med brus. Det kan inte ens användas + för att göra en lämplig ändringslogg ens i ett hypotetiskt projekt drivet av + perfekta människor som aldrig skriver fel, aldrig glömmer att checka in nya filer + eller aldrig glömmer någon del av en refaktorering. Syftet med en commit är att + dokumentera ett enskilt steg i processen då koden utvecklas från ett tillstånd till + ett annat. Syftet med en ändringslogg är att dokumentera de anmärkningsvärda + skillnaderna mellan dessa tillstånd. + + På samma sätt som det är skillnad mellan bra kommentarer och själva koden, + är det skillnad mellan ändringsloggen och commit-loggen: + en beskriver "varför" och den andra "hur". + + ### Kan ändringsloggar bli automatiskt tolkade? + Det är svårt då människor följer vitt olika format och filnamn. + + [Vandamme][vandamme] är en Ruby gem + skapad av gruppen bakom [Gemnasium][gemnasium] som tolkar många (men inte alla) + ändringsloggar för öppen källkod. + + ### Varför alternerar du mellan att skriva det som "CHANGELOG" och "ändringslogg"?" + "CHANGELOG" är namnet på själva filen. Det sticker ut lite, men det är en + historisk konvention använt i många öppen källkodsprojekt. Andra + exempel på liknande filer är [`README`][README], [`LICENSE`][LICENSE] + och [`CONTRIBUTING`][CONTRIBUTING]. + + De stora bokstäverna i namnen (som gjorde att de i äldre operativsystem + hamnade högst upp) används för att dra uppmärksamhet till dem. Då de är + viktig metadata om projektet borde de vara användbara för att alla som + vill använda eller bidra till det, ungefär som [open source project badges][shields]. + + När jag refererar till "ändringslogg" pratar jag om syftet med denna fil: + att logga ändringar. + + ### Hur är det med brådskande utgåvor ("yanked")? + Brådskande utgåvor är versioner som måste släppas p.g.a. alvarliga + buggar eller säkerhetsproblem. Oftast brukar dessa versioner inte ens + finnas med i ändringsloggarna. De borde det. Så här borde du visa dem: + + `## 0.0.5 - 2014-12-13 [YANKED]` + + Taggen `[YANKED]` står ut av en anledning, det är viktigt för människor + att se den. Då den är omsluten med hakparenteser är det också lättare + för ett program att tolka. + + ### Borde du någonsin förändra en ändringslogg? + Självklart. Det finns alltid en bra anlending att förbättra en ändringslogg. + Jag öppnar regelbundet pull requests för att lägga till saknade utgåvor + för öppen källkodsprojekt som inte tar hand om sin ändringslogg. + + Det kan också hända att du upptäcker att du glömt att ta upp en icke + bakåtkompatibel förändring i en version. I sådana fall är det självklart + viktigt att uppdatera din ändringslogg. + + ### Hur kan jag bidra? + Detta dokument är inte **sanningen**, det är en noga övervägd åsikt + tillsammans med information och exempel jag har samlat på mig. + Även om jag tillhandahåller en [CHANGELOG][] i min [GitHub repo][gh], + har jag avsiktligt inte skapat en egentlig *utgåva* eller en tydlig lista + med regler att följa (som t.ex. [SemVer.org][semver] gör). + + Detta beror på att jag vill att vår gemenskap ska nå samförstånd. Jag + tror att diskussionen är lika viktig som slutresultatet. + + Så välkomna att [**diskutera**]][gh]. + + [CHANGELOG]: https://github.com/olivierlacan/keep-a-changelog/blob/master/CHANGELOG.md + [CONTRIBUTING]: https://github.com/olivierlacan/keep-a-changelog/blob/master/CONTRIBUTING.md + [LICENSE]: https://github.com/olivierlacan/keep-a-changelog/blob/master/LICENSE + [README]: https://github.com/olivierlacan/keep-a-changelog/blob/master/README.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/