Merge pull request #250 from m-aciek/master

Polish translation improvements, link bugfix, added line to changelog…

CHANGELOG.md

@@ -5,6 +5,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]
+### Changed
+- Update and improvement of Polish translation from [@m-aciek](https://github.com/m-aciek).
 
 ## [1.0.0] - 2017-06-20
 ### Added

config.rb

@@ -5,7 +5,7 @@
 # ----- Site ----- #
 # Last version should be the latest English version since the manifesto is first
 # written in English, then translated into other languages later.
-$versions = (Dir.entries("source/en") - %w[. ..])
+$versions = (Dir.entries("source/en").sort - %w[. ..])
 $last_version = $versions.last
 $previous_version = $versions[$versions.index($last_version) - 1]
 
@@ -110,7 +110,7 @@ redirect "index.html", to: "en/#{$last_version}/index.html"
 
 $languages.each do |language|
   code = language.first
-  versions = Dir.entries("source/#{code}") - %w[. ..]
+  versions = Dir.entries("source/#{code}").sort - %w[. ..]
   redirect "#{code}/index.html", to: "#{code}/#{versions.last}/index.html"
 end
 

source/pl/1.0.0/index.html.haml

@@ -33,7 +33,8 @@ version: 1.0.0
     Czym jest changelog?
   %p
     Changelog, inaczej rejestr zmian, to plik zawierający utrzymywaną,
-    chronologicznie uporządkowaną listę istotnych zmian dla każdej wersji projektu.
+    uporządkowaną chronologicznie, listę istotnych zmian dla każdej wersji
+    projektu.
 
   %h3#why
     %a.anchor{ href: "#why", aria_hidden: "true" }
@@ -70,34 +71,34 @@ version: 1.0.0
     %li
       Wersje i sekcje powinny być linkowalne.
     %li
-      Najnowsza wersja jest na pierwszym miejscu.
+      Najnowsza wersja na pierwszym miejscu.
     %li
-      Wyszczególniona jest data wydania każdej wersji.
+      Wyszczególniona data wydania każdej wersji.
     %li
-      Wzmianka, czy przestrzegasz #{link_to "wersjonowania semantycznego", semver}.
+      Wzmianka, czy przestrzegacie #{link_to "wersjonowania semantycznego", semver}.
 
   %a.anchor{ href: "#types", aria_hidden: "true" }
   %h4#types Typy zmian
 
   %ul
     %li
-      %code Added
+      %code Dodane
       dla nowych funkcjonalności.
     %li
-      %code Changed
+      %code Zmienione
       dla zmian w istniejących funkcjonalnościach.
     %li
-      %code Deprecated
+      %code Zdezaprobowane
       dla funkcjonalności wkrótce do usunięcia.
     %li
-      %code Removed
-      dla teraz usuniętych funkcjonalności.
+      %code Usunięte
+      dla teraz usuwanych funkcjonalności.
     %li
-      %code Fixed
+      %code Naprawione
       dla jakichkolwiek poprawek błędów.
     %li
-      %code Security
-      w przypadku luk w zabezpieczeniach.
+      %code Bezpieczeństwo
+      w przypadku luk w zabezpieczeniach.
 
 .effort
 
@@ -105,16 +106,17 @@ version: 1.0.0
     %a.anchor{ href: "#effort", aria_hidden: "true" }
     Jak mogę zminimalizować wysiłek wkładany w prowadzenie changelogu?
   %p
-    Prowadź sekcję <code>Unreleased</code> na szczycie dokumentu, aby śledzić
+    Prowadź sekcję <code>Niewydane</code> na szczycie dokumentu, aby śledzić
     nadchodzące zmiany.
 
   %p Ta praktyka ma dwa cele:
 
   %ul
     %li
-      Ludzie widzą, jakich zmian mogą się spodziewać w nadchodzących wydaniach.
+      Ludzie widzą, jakich zmian mogą się spodziewać w&nbsp;nadchodzących
+      wydaniach.
     %li
-      W momencie wydania możesz przenieść zmiany z sekcji <code>Unreleased</code>
+      W momencie wydania możesz przenieść zmiany z sekcji <code>Niewydane</code>
       do sekcji nowego wydania.
 
 .bad-practices
@@ -129,32 +131,33 @@ version: 1.0.0
     Zmiany w commit logu
 
   %p
-    Używanie zmian w commit logach jako changelogów jest złym pomysłem: są pełne
-    szumu. Rzeczy takich jak merge commity, commity z niejasnymi tytułami,
-    zmiany w dokumentacji itp.
+    Używanie zmian w commit logach jako changelogów jest złym pomysłem: commit
+    logi są pełne szumu: rzeczy takich jak merge commity, commity z niejasnymi
+    tytułami, zmiany w&nbsp;dokumentacji itp.
 
   %p
-    Zadaniem commita jest udokumentowanie kroku w ewolucji kodu źródłowego.
+    Zadaniem commita jest udokumentowanie kroku w&nbsp;ewolucji kodu źródłowego.
     Niektóre projekty porządkują commity, niektóre nie.
 
   %p
     Zadaniem wpisu w changelogu jest udokumentowanie zmian godnych odnotowania,
-    często składających się z wielu commitów, aby przedstawić je jasno
+    często składających się z&nbsp;wielu commitów, aby przedstawić je jasno
     użytkownikom końcowym.
 
   %h4#ignoring-deprecations
     %a.anchor{ href: "#ignoring-deprecations", aria_hidden: "true" }
-    Ignorowanie deprecjacji
+    Ignorowanie dezaprobowań
 
   %p
-    Gdy ludzie robią upgrade z jednej wersji na drugą, powinno być bezboleśnie
-    jasne kiedy coś się złamie. Powinno być możliwe upgrade'owanie się do wersji,
-    która wypisuje deprecjacje, usunięcie tego, co jest zdezaprobowane, następnie
-    upgrade'owanie się do wersji, w której deprecjacje stają się usunięciami.
+    Gdy ludzie robią upgrade z jednej wersji do drugiej, powinno być bezboleśnie
+    jasne kiedy coś się może zepsuć. Powinno być możliwe upgrade'owanie się do
+    wersji, która wypisuje zdezaprobowania, usunięcie tego, co jest
+    zdezaprobowane, następnie upgrade'owanie się do wersji, w której
+    dezaprobowane funkcjonalności są usuwane.
 
   %p
-    Jeśli nie robisz nic więcej, wypisz deprecjacje, usunięcia i jakiekolwiek
-    zmiany łamiące zgodność wstecz w swoim changelogu.
+    Jeśli nie robisz nic innego, wypisz w swoim changelogu zdezaprobowania,
+    usunięcia i&nbsp;jakiekolwiek zmiany łamiące zgodność wstecz.
 
   %h4#confusing-dates
     %a.anchor{ href: "#confusing-dates", aria_hidden: "true" }
@@ -163,13 +166,13 @@ version: 1.0.0
   %p
     Regionalne formaty dat różnią się na świecie i często trudno jest znaleźć
     przyjazny człowiekowi format daty, który wydaje się intuicyjny wszystkim.
-    Zaletą dat sformatowanych jak <code>2017-07-17</code> jest to, że są one
+    Zaletą dat sformatowanych tak jak <code>2017-07-17</code> jest to, że są one
     uporządkowane od największych do najmniejszych jednostek: roku, miesiąca
     i dnia. Ten format również nie nachodzi w niejednoznaczny sposób na inne
     formaty dat, w przeciwieństwie do niektórych regionalnych formatów, które
     zamieniają miejsce numerów miesiąca i dnia. Z tych powodów i faktu, że
-    ten format daty jest #({link_to "standardem ISO", iso}, wynika rekomendacja
-    tego formatu daty do wpisów w changelogu.
+    ten format daty jest #{link_to "standardem ISO", iso}, wynika rekomendacja
+    tego formatu daty do wpisów w&nbsp;changelogu.
 
   %aside
     Jest tego więcej. Pomóż mi zebrać te antywzorce
@@ -192,7 +195,8 @@ version: 1.0.0
   %p
     Ten projekt pretenduje do bycia
     = link_to "lepszą konwencją changelogu.", changelog
-    Pochodzi z obserwowania dobrych praktyk w społeczności open source i zebrania ich.
+    Pochodzi z obserwowania i zebrania dobrych praktyk w społeczności open
+    source.
 
   %p
     Zdrowa krytyka, dyskusja i sugestie poprawek
@@ -209,8 +213,8 @@ version: 1.0.0
 
   %p
     Łatwo jest uznać, że nazwa pliku z changelogiem nie ma większego znaczenia,
-    lecz po co utrudniać swoim końcowym użytkownikom w sposób konsewenty
-    odnajdować istotne zmiany?
+    lecz po co utrudniać swoim użytkownikom końcowym odnajdowanie w sposób
+    konsekwentny istotnych zmian?
 
   %h4#github-releases
     %a.anchor{ href: "#github-releases", aria_hidden: "true" }
@@ -220,7 +224,7 @@ version: 1.0.0
     To wspaniała inicjatywa. #{link_to "Releases", ghr} mogą być używane do
     zmiany prostych tagów Gita (na przykład taga nazwanego <code>v1.0.0</code>)
     w bogate informacje o wydaniach przez ręczne dodanie informacji lub mogą
-    wyciągać oznaczone message taga i przekształcać je w informacje.
+    wyciągać oznaczone message tagów i przekształcać je w informacje.
 
   %p
     GitHub Releases tworzą nieprzenośny changelog, który może być prezentowany
@@ -228,7 +232,7 @@ version: 1.0.0
     formatu Prowadź changelog, ale będzie to dość skomplikowane.
 
   %p
-    Bieżąca wersja wydań GitHub jest też prawdopodobnie nie najłatwiejsza do
+    Bieżąca wersja wydań GitHub jest też prawdopodobnie nienajłatwiejsza do
     odnalezienia dla użytkowników końcowych, w przeciwieństwie do plików
     o nazwach z wielkimi literami (<code>README</code>, <code>CONTRIBUTING</code>
     itp.). Innym mniejszym brakiem jest to, że interfejs obecnie nie posiada
@@ -256,10 +260,10 @@ version: 1.0.0
     poważnego błędu lub problemów z bezpieczeństwem. Często te wersje nie
     pojawiają się w dziennikach zmian. Powinny. Tak powinieneś je wyświetlać:
 
-  %p <code>## 0.0.5 - 2014-12-13 [YANKED]</code>
+  %p <code>## 0.0.5 - 2014-12-13 [WYCOFANA]</code>
 
   %p
-    Etykieta <code>[YANKED]</code> jest celowo zapisany wielkimi literami.
+    Etykieta <code>[WYCOFANA]</code> jest celowo zapisana wielkimi literami.
     Ważne jest, by zwracano na nią uwagę. Jest otoczona nawiasami, więc jest
     również prostsza do sparsowania przez skrypt.
 
@@ -284,15 +288,15 @@ version: 1.0.0
     Jak mogę wnieść swój wkład?
 
   %p
-    Ten dokument nie jest obiektywną **prawdą**; jest moją starannie przemyślaną
-    opinią, z informacjami i przykładami, które zebrałem.
+    Ten dokument nie jest obiektywną <strong>prawdą</strong>; jest moją
+    starannie przemyślaną opinią, z informacjami i przykładami, które zebrałem.
 
   %p
     To dlatego, że chcę, aby nasza społeczność osiągnęła konsensus. Wierzę, że
     dyskusja jest tak samo istotna jak efekt końcowy.
 
   %p
-    Więc proszę, <strong>#{link_to "zabieraj się za robotę", gh}</strong>.
+    Więc proszę, <strong>#{link_to "wtrąć się", gh}</strong>.
 
 .press
   %h3 Rozmowy