Merge pull request #118 from magol/sv

Swedish translation

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

config.rb

@@ -11,7 +11,8 @@ $languages = {
   "pt-BR" => "Brazilian Portugese",
   ru: "Pyccкий",
   "zh-CN" => "简体中文",
-  "zh-TW" => " 繁體中文"
+  "zh-TW" => " 繁體中文",
+  "sv"    => "Svenska"
 }
 
 activate :i18n,

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/