From e6937c1bc6b2f5af0c063971ade754c6770d12b0 Mon Sep 17 00:00:00 2001 From: roalz Date: Wed, 11 May 2016 10:21:46 +0200 Subject: [PATCH 1/5] Added it-IT index.haml --- source/it-IT/index.haml | 178 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 178 insertions(+) create mode 100644 source/it-IT/index.haml diff --git a/source/it-IT/index.haml b/source/it-IT/index.haml new file mode 100644 index 0000000..c1e3dc3 --- /dev/null +++ b/source/it-IT/index.haml @@ -0,0 +1,178 @@ +--- +description: Keep a Changelog +title: Keep a Changelog +language: it +--- + +:markdown + # Mantenere un CHANGELOG + + ## Non lasciate che i vostri amici copino e incollino i git log nei CHANGELOG ™ + + ### Cos'è un change log? + Un change log è un file che contiene una lista curata e ordinata cronologicamente delle modifiche degne di nota per ogni versione di un progetto. + +%pre.changelog= File.read(File.expand_path("../../CHANGELOG.md", __FILE__)) + +:markdown + ### A cosa serve un change log? + Per rendere facile agli utilizzatori e contributors vedere con precisione quali modifiche + importanti sono state fatte tra ogni release (o versione) del progetto + + ### Why should I care? + Because software tools are for people. If you don’t care, why are + you contributing to open source? Surely, there must be a kernel (ha!) + of care somewhere in that lovely little brain of yours. + + I [talked with Adam Stacoviak and Jerod Santo on The Changelog][thechangelog] + (fitting, right?) podcast about why maintainers and + contributors should care, and the motivations behind this project. + If you can spare the time (1:06), it’s a good listen. + + ### What makes a good change log? + I’m glad you asked. + + Un buon change log si attiene ai seguenti principi: + + - It’s made for humans, not machines, so legibility is crucial. + - Easy to link to any section (hence Markdown over plain text). + - Una sotto-sezione per ogni versione. + - Elenca le release in ordine cronologico inverso (quelle più recenti all'inizio). + - Scrive tutte le date nel formato `YYYY-MM-DD`. (Esempio: `2012-06-02` sta per `2 Giugno 2012`). è internazionale, [sensible](http://xkcd.com/1179/), e indipendente dalla lingua. + - Explicitly mention whether the project follows [Semantic Versioning][semver]. + - Ogni versione dovrebbe: + - Elencare la sua data di rilascio nel formato specificato sopra. + - Group changes to describe their impact on the project, as follows: + - `Added` for new features. + - `Changed` for changes in existing functionality. + - `Deprecated` for once-stable features removed in upcoming releases. + - `Removed` for deprecated features removed in this release. + - `Fixed` for any bug fixes. + - `Security` to invite users to upgrade in case of vulnerabilities. + + ### Come posso minimizzare lo sforzo richiesto? + Usa sempre una sezione `"Unreleased"` all'inizio per tenere traccia di qualsiasi modifica. + + Questo serve per due scopi: + + - People can see what changes they might expect in upcoming releases + - At release time, you just have to change `"Unreleased"` to the version number + and add a new `"Unreleased"` header at the top. + + ### What makes unicorns cry? + Alright…let’s get into it. + + - **Dumping a diff of commit logs.** Just don’t do that, you’re helping nobody. + - **Not emphasizing deprecations.** When people upgrade from one version to + another, it should be painfully clear when something will break. + - **Dates in region-specific formats.** In the U.S., people put the month first + ("06-02-2012" for June 2nd, 2012, which makes *no* sense), while many people + in the rest of the world write a robotic-looking "2 June 2012", yet pronounce + it differently. "2012-06-02" works logically from largest to smallest, doesn't + overlap in ambiguous ways with other date formats, and is an + [ISO standard](http://www.iso.org/iso/home/standards/iso8601.htm). Thus, it + is the recommended date format for change logs. + + There’s more. Help me collect those unicorn tears by + [opening an issue][issues] + or a pull request. + + ### Is there a standard change log format? + Sadly, no. Calm down. I know you're furiously rushing to find that link + to the GNU change log style guide, or the two-paragraph GNU NEWS file + "guideline". The GNU style guide is a nice start but it is sadly naive. + There's nothing wrong with being naive but when people need + guidance it's rarely very helpful. Especially when there are many + situations and edge cases to deal with. + + This project [contains what I hope will become a better CHANGELOG file convention][CHANGELOG]. + I don't think the status quo is good enough, and I think that as a community we + can come up with better conventions if we try to extract good practices from + real software projects. Please take a look around and remember that + [discussions and suggestions for improvements are welcome][issues]! + + ### What should the change log file be named? + Well, if you can’t tell from the example above, `CHANGELOG.md` is the + best convention so far. + + Some projects also use `HISTORY.txt`, `HISTORY.md`, `History.md`, `NEWS.txt`, + `NEWS.md`, `News.txt`, `RELEASES.txt`, `RELEASE.md`, `releases.md`, etc. + + It’s a mess. All these names only makes it harder for people to find it. + + ### Why can’t people just use a `git log` diff? + Because log diffs are full of noise — by nature. They could not make a suitable + change log even in a hypothetical project run by perfect humans who never make + typos, never forget to commit new files, never miss any part of a refactoring. + The purpose of a commit is to document one atomic step in the process by which + the code evolves from one state to another. The purpose of a change log is to + document the noteworthy differences between these states. + + As is the difference between good comments and the code itself, + so is the difference between a change log and the commit log: + one describes the *why*, the other the how. + + ### Can change logs be automatically parsed? + It’s difficult, because people follow wildly different formats and file names. + + [Vandamme][vandamme] is a Ruby gem + created by the [Gemnasium][gemnasium] team and which parses + many (but not all) open source project change logs. + + ### Why do you alternate between spelling it "CHANGELOG" and "change log"? + "CHANGELOG" is the name of the file itself. It's a bit shouty but it's a + historical convention followed by many open source projects. Other + examples of similar files include [`README`][README], [`LICENSE`][LICENSE], + and [`CONTRIBUTING`][CONTRIBUTING]. + + The uppercase naming (which in old operating systems made these files stick + to the top) is used to draw attention to them. Since they're important + metadata about the project, they could be useful to anyone intending to use + or contribute to it, much like [open source project badges][shields]. + + When I refer to a "change log", I'm talking about the function of this + file: to log changes. + + ### What about yanked releases? + Yanked releases are versions that had to be pulled because of a serious + bug or security issue. Often these versions don't even appear in change + logs. They should. This is how you should display them: + + `## 0.0.5 - 2014-12-13 [YANKED]` + + The `[YANKED]` tag is loud for a reason. It's important for people to + notice it. Since it's surrounded by brackets it's also easier to parse + programmatically. + + ### Should you ever rewrite a change log? + Sure. There are always good reasons to improve a change log. I regularly open + pull requests to add missing releases to open source projects with unmaintained + change logs. + + It's also possible you may discover that you forgot to address a breaking change + in the notes for a version. It's obviously important for you to update your + change log in this case. + + ### Come posso contribuire? + Questo documento non e' la **verità**; it’s my carefully considered + opinion, along with information and examples I gathered. + Although I provide an actual [CHANGELOG][] on [the GitHub repo][gh], + I have purposefully not created a proper *release* or clear list of rules + to follow (as [SemVer.org][semver] does, for instance). + + This is because I want our community to reach a consensus. I believe the + discussion is as important as the end result. + + So please [**pitch in**][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/ From 118c05b184f85c7294c0e70672008e36b1c5d5ef Mon Sep 17 00:00:00 2001 From: roalz Date: Wed, 11 May 2016 12:09:59 +0200 Subject: [PATCH 2/5] Completed translation of index.haml to Italian --- source/it-IT/index.haml | 220 ++++++++++++++++++++-------------------- 1 file changed, 109 insertions(+), 111 deletions(-) diff --git a/source/it-IT/index.haml b/source/it-IT/index.haml index c1e3dc3..4a37976 100644 --- a/source/it-IT/index.haml +++ b/source/it-IT/index.haml @@ -1,7 +1,7 @@ --- description: Keep a Changelog title: Keep a Changelog -language: it +language: it-IT --- :markdown @@ -10,160 +10,158 @@ language: it ## Non lasciate che i vostri amici copino e incollino i git log nei CHANGELOG ™ ### Cos'è un change log? - Un change log è un file che contiene una lista curata e ordinata cronologicamente delle modifiche degne di nota per ogni versione di un progetto. + Un change log è un file che contiene una lista curata e ordinata cronologicamente + delle modifiche degne di nota per ogni versione di un progetto. %pre.changelog= File.read(File.expand_path("../../CHANGELOG.md", __FILE__)) :markdown ### A cosa serve un change log? - Per rendere facile agli utilizzatori e contributors vedere con precisione quali modifiche - importanti sono state fatte tra ogni release (o versione) del progetto + Per rendere facile agli utilizzatori e contribuenti vedere con precisione quali modifiche + importanti sono state fatte tra ogni release (o versione) del progetto. - ### Why should I care? - Because software tools are for people. If you don’t care, why are - you contributing to open source? Surely, there must be a kernel (ha!) - of care somewhere in that lovely little brain of yours. + ### Perché dovrebbe importarmi? + Perché gli strumenti software sono fatti per le persone. + Se non ti importa, perché contribuisci all'open source? + Di certo ci deve essere un "kernel" (ha!) di interesse + da qualche parte in quel tuo amorevole cervello. - I [talked with Adam Stacoviak and Jerod Santo on The Changelog][thechangelog] - (fitting, right?) podcast about why maintainers and - contributors should care, and the motivations behind this project. - If you can spare the time (1:06), it’s a good listen. + [Nel podcast "The Changelog" con Adam Stacoviak e Jerod Santo][thechangelog] + (titolo appropriato, vero?) ho parlato del perché maintainer e contribuenti + dovrebbero esserne interessati, e delle motivazioni dietro a questo progetto. + Se avete tempo (1:06), vale la pena ascoltarlo. - ### What makes a good change log? - I’m glad you asked. + ### Come si può fare un buon change log? + Sono contento che tu l'abbia chiesto. - Un buon change log si attiene ai seguenti principi: + Un buon change log è guidato dai seguenti principi: - - It’s made for humans, not machines, so legibility is crucial. - - Easy to link to any section (hence Markdown over plain text). + - È fatto per umani, non macchine, quindi la leggibilità è cruciale. + - Facile da linkare ad altre sezioni (da cui il Markdown invece che testo normale). - Una sotto-sezione per ogni versione. - Elenca le release in ordine cronologico inverso (quelle più recenti all'inizio). - - Scrive tutte le date nel formato `YYYY-MM-DD`. (Esempio: `2012-06-02` sta per `2 Giugno 2012`). è internazionale, [sensible](http://xkcd.com/1179/), e indipendente dalla lingua. - - Explicitly mention whether the project follows [Semantic Versioning][semver]. + - Scrive tutte le date nel formato `YYYY-MM-DD`. (Esempio: `2012-06-02` sta per `2 Giugno 2012`). È internazionale, [sensato](http://xkcd.com/1179/), e indipendente dalla lingua. + - Dichiara esplicitamente se il progetto segue il [Semantic Versioning][semver]. - Ogni versione dovrebbe: - - Elencare la sua data di rilascio nel formato specificato sopra. - - Group changes to describe their impact on the project, as follows: - - `Added` for new features. - - `Changed` for changes in existing functionality. - - `Deprecated` for once-stable features removed in upcoming releases. - - `Removed` for deprecated features removed in this release. - - `Fixed` for any bug fixes. - - `Security` to invite users to upgrade in case of vulnerabilities. + - Elencare la sua data di rilascio nel formato sopra specificato. + - Raggruppare le modifiche per descrivere il loro impatto sul progetto, come segue: + - `Added` per le nuove funzionalità. + - `Changed` per le modifiche a funzionalità esistenti. + - `Deprecated` per vecchie feature stabili che verranno rimosse nelle future release. + - `Removed` per funzionalità precedentemente deprecate rimosse in questa release. + - `Fixed` per tutti i bug fix. + - `Security` per invitare gli utilizzatori ad aggiornare in caso di vulnerabilità. ### Come posso minimizzare lo sforzo richiesto? Usa sempre una sezione `"Unreleased"` all'inizio per tenere traccia di qualsiasi modifica. Questo serve per due scopi: - - People can see what changes they might expect in upcoming releases - - At release time, you just have to change `"Unreleased"` to the version number - and add a new `"Unreleased"` header at the top. + - La gente può vedere quali modifiche si può aspettare in future release + - Ad una nuova release, si deve solo sostituire `"Unreleased"` con il numero di versione + e aggiungere una nuova sezione `"Unreleased"` all'inizio. - ### What makes unicorns cry? - Alright…let’s get into it. + ### Cosa fa piangere gli unicorni? + Bene...vediamo un po'. - - **Dumping a diff of commit logs.** Just don’t do that, you’re helping nobody. - - **Not emphasizing deprecations.** When people upgrade from one version to - another, it should be painfully clear when something will break. - - **Dates in region-specific formats.** In the U.S., people put the month first - ("06-02-2012" for June 2nd, 2012, which makes *no* sense), while many people - in the rest of the world write a robotic-looking "2 June 2012", yet pronounce - it differently. "2012-06-02" works logically from largest to smallest, doesn't - overlap in ambiguous ways with other date formats, and is an - [ISO standard](http://www.iso.org/iso/home/standards/iso8601.htm). Thus, it - is the recommended date format for change logs. + - **Copia&incolla un diff di commig log.** Non fatelo, così non aiutate nessuno. + - **Non enfatizzare le funzioni deprecate.** Quando le persone aggiornano da una versione ad un'altra, + dovrebbe essere dolorosamente chiaro quando qualcosa si romperà. + - **Date in formati specifici per regione.** Negli Stati Uniti si mette prima il mese nelle date + ("06-02-2012" sta per 2 Giugno 2012, che non ha senso), mentre molte persone + nel resto del mondo scrivono un robotico "2 June 2012", ma lo pronunciano diversamente. + "2012-06-02" funziona con la logica dal più grande al più piccolo, non ha sovrapposizioni + ambigue con altri formati di date, ed è uno [standard ISO](http://www.iso.org/iso/home/standards/iso8601.htm). + Per tutti questi motivi, è il formato di date raccomandato per i change log. - There’s more. Help me collect those unicorn tears by - [opening an issue][issues] - or a pull request. + C'è di più. Aiutatemi a collezionare queste "lacrime di unicorno" [aprendo una "issue"][issues] + o una pull request. - ### Is there a standard change log format? - Sadly, no. Calm down. I know you're furiously rushing to find that link - to the GNU change log style guide, or the two-paragraph GNU NEWS file - "guideline". The GNU style guide is a nice start but it is sadly naive. - There's nothing wrong with being naive but when people need - guidance it's rarely very helpful. Especially when there are many - situations and edge cases to deal with. + ### Esiste un formato standard per i change log? + Purtroppo no. Calma. So che state furiosamente correndo a cercare quel link + alla guida di stile per i change log GNU, o alle linee guida per or il file a due paragrafi GNU NEWS. + La guida GNU è un buon punto di partenza, ma è tristemente ingenuo. + Non c'è nulla di male nell'essere ingenuo, ma quando le persone cercano una guida, questa caratteristica + è raramente d'aiuto. Specialmente se ci sono molte situazioni e casi limite da gestire. - This project [contains what I hope will become a better CHANGELOG file convention][CHANGELOG]. - I don't think the status quo is good enough, and I think that as a community we - can come up with better conventions if we try to extract good practices from - real software projects. Please take a look around and remember that - [discussions and suggestions for improvements are welcome][issues]! + Questo progetto [contiene ciò che spero diventerà una migliore convenzione per i file CHANGELOG][CHANGELOG]. + Non credo che lo status quo sia sufficientemente buono, e penso che noi, come comunità, + possiamo arrivare a convenzioni migliori se tentiamo di estrarre le pratiche migliori + da progetti software reali. Vi consiglio di guardarvi intorno e ricordare che + [ogni discussione e suggerimento per migliorare sono sempre benvenuti][issues]! - ### What should the change log file be named? - Well, if you can’t tell from the example above, `CHANGELOG.md` is the - best convention so far. + ### Come si dovrebbe chiamare il file contenente il change log? + Se non l'avete dedotto dall'esempio qui sopra, `CHANGELOG.md` è la convenzione migliore finora. - Some projects also use `HISTORY.txt`, `HISTORY.md`, `History.md`, `NEWS.txt`, + Alcuni progetti usano anche `HISTORY.txt`, `HISTORY.md`, `History.md`, `NEWS.txt`, `NEWS.md`, `News.txt`, `RELEASES.txt`, `RELEASE.md`, `releases.md`, etc. - It’s a mess. All these names only makes it harder for people to find it. + È un disastro. Tutti questi nomi contribuiscono solo a rendere più difficile trovarlo. - ### Why can’t people just use a `git log` diff? - Because log diffs are full of noise — by nature. They could not make a suitable - change log even in a hypothetical project run by perfect humans who never make - typos, never forget to commit new files, never miss any part of a refactoring. - The purpose of a commit is to document one atomic step in the process by which - the code evolves from one state to another. The purpose of a change log is to - document the noteworthy differences between these states. + ### Perché la gente non si limita ad usare diff di `git log`? + Perché i log diff sono pieni di rumore, per loro natura. Non potrebbero creare un change log + decente nemmeno in un ipotetico progetto gestito da perfetti umani che non fanno mai errori + di digitazione, non dimenticano mai di fare commit dei nuovi file, non dimenticano mai + alcuna parte di un refactoring. + Lo scopo di un commit è di documentare un passo atomico nel processo di evoluzione del codice + da uno stato ad un altro. Lo scopo di un change log è di documentare le differenze + degne di nota tra questi stati. - As is the difference between good comments and the code itself, - so is the difference between a change log and the commit log: - one describes the *why*, the other the how. + La differenza tra un change log e un commit log è + come la differenza tra un buon commento nel codice e il codice stesso: + uno descrive il *perché*, l'altro il come. - ### Can change logs be automatically parsed? - It’s difficult, because people follow wildly different formats and file names. + ### Si possono analizzare automaticamente i change log? + È difficile, perché le persone usano formati e nomi di file profondamente diversi. + + [Vandamme][vandamme] è una Ruby gem + creata dal team [Gemnasium][gemnasium] ed è in grado di fare il parsing dei + change log di molti (ma non tutti) i progetti open source. - [Vandamme][vandamme] is a Ruby gem - created by the [Gemnasium][gemnasium] team and which parses - many (but not all) open source project change logs. + ### Perché si alterna tra i nomi "CHANGELOG" e "change log"? + "CHANGELOG" è il nome del file. È un po' invadente ma è una + convenzione storica seguita da molti progetti open source. + Altri esempi di file simili includono [`README`][README], [`LICENSE`][LICENSE], + e [`CONTRIBUTING`][CONTRIBUTING]. - ### Why do you alternate between spelling it "CHANGELOG" and "change log"? - "CHANGELOG" is the name of the file itself. It's a bit shouty but it's a - historical convention followed by many open source projects. Other - examples of similar files include [`README`][README], [`LICENSE`][LICENSE], - and [`CONTRIBUTING`][CONTRIBUTING]. + I nomi in maiuscolo (che su vecchi sistemi operativi erano ordinati per primi) + vengono usati per attirare l'attenzione su di essi. Poiché sono metadati + importanti relativi al progetto, possono essere utili per chiunque voglia usarlo + o contribuire ad esso, un po' come i [badge dei progetti open source][shields]. - The uppercase naming (which in old operating systems made these files stick - to the top) is used to draw attention to them. Since they're important - metadata about the project, they could be useful to anyone intending to use - or contribute to it, much like [open source project badges][shields]. + Quando mi riferisco a un "change log", sto parlando della funzione di questo file: + registrare le modifiche. - When I refer to a "change log", I'm talking about the function of this - file: to log changes. - - ### What about yanked releases? - Yanked releases are versions that had to be pulled because of a serious - bug or security issue. Often these versions don't even appear in change - logs. They should. This is how you should display them: + ### Cosa sono le release "yanked"? + Le release "yanked" sono versioni che sono state rimosse a causa di bug seri + o problemi di sicurezza. Spesso queste versioni non appaiono nei change + log. Invece dovrebbero esserci, nel seguente modo: `## 0.0.5 - 2014-12-13 [YANKED]` - The `[YANKED]` tag is loud for a reason. It's important for people to - notice it. Since it's surrounded by brackets it's also easier to parse - programmatically. + L'etichetta `[YANKED]` è in maiuscolo per un motivo. È importante che la gente la noti. + Poiché è racchiusa tra parentesi quadre è anche più semplice da riconoscere nel parsing automatizzato. - ### Should you ever rewrite a change log? - Sure. There are always good reasons to improve a change log. I regularly open - pull requests to add missing releases to open source projects with unmaintained - change logs. + ### Si dovrebbe mai modificare un change log? + Certo. Ci sono sempre buoni motivi per migliorare un change log. Io apro regolarmente + delle pull request per aggiungere release mancanti ai progetti open source che non mantengono + correttamente i change log. - It's also possible you may discover that you forgot to address a breaking change - in the notes for a version. It's obviously important for you to update your - change log in this case. + È anche possibile che si scopra di aver dimenticato di annotare una modifica + non retro-compatibile nelle note per una versione. Ovviamente è importante aggiornare + il change log in questo caso. ### Come posso contribuire? - Questo documento non e' la **verità**; it’s my carefully considered - opinion, along with information and examples I gathered. - Although I provide an actual [CHANGELOG][] on [the GitHub repo][gh], - I have purposefully not created a proper *release* or clear list of rules - to follow (as [SemVer.org][semver] does, for instance). + Questo documento non è la **verità assoluta**; è solo la mia attenta + opinione, arricchita dalle informazioni ed esempi che ho raccolto. + Anche se fornisco un [CHANGELOG][] reale sul [repository GitHub][gh], + ho volutamente evitato di creare una *release* o una chiara lista di regole + da seguire (come fa, ad esempio, [SemVer.org][semver]). - This is because I want our community to reach a consensus. I believe the - discussion is as important as the end result. + Questo è perché voglio che la nostra comunità raggiunga un consenso. Credo che + la discussione sia importante almeno quanto il risultato finale. - So please [**pitch in**][gh]. + Quindi per favore [**partecipate**][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 From b7d3af1ad693bbbf4693f166d054391a2d403d12 Mon Sep 17 00:00:00 2001 From: roalz Date: Wed, 11 May 2016 12:12:24 +0200 Subject: [PATCH 3/5] Update layout.haml --- source/layouts/layout.haml | 1 + 1 file changed, 1 insertion(+) diff --git a/source/layouts/layout.haml b/source/layouts/layout.haml index 38e0140..30edac3 100644 --- a/source/layouts/layout.haml +++ b/source/layouts/layout.haml @@ -33,6 +33,7 @@ %ul %li= link_to 'english [en]', '/', {rel: "alternate", lang: "en", hreflang: "en"} %li= link_to 'español [es-ES]', '/es-ES/', {rel: "alternate", lang: "es-ES", hreflang: "es-ES"} + %li= link_to 'italiano [it-IT]', '/it-IT/', {rel: "alternate", lang: "it-IT", hreflang: "it-IT"} %li= link_to 'português brasileiro [pt-BR]', '/pt-BR/', {rel: "alternate", lang: "pt-BR", hreflang: "pt-BR"} %li= link_to 'pyccкий [ru]', '/ru/', {rel: "alternate", lang: "ru", hreflang: "ru"} %li= link_to '简体中文 [zh-CN]', '/zh-CN/', {rel: "alternate", lang: "zh-CN", hreflang: "zh-CN"} From 4f6ff42c6aa7139ba17baedac4f349b57cc57578 Mon Sep 17 00:00:00 2001 From: roalz Date: Wed, 11 May 2016 12:13:06 +0200 Subject: [PATCH 4/5] Update CHANGELOG.md --- CHANGELOG.md | 1 + 1 file changed, 1 insertion(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index b4e2b6b..fbae298 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. +- it-IT translation from @roalz. ## [0.3.0] - 2015-12-03 ### Added From 8935a1d5080dd6bbc836103693bf4f222de274c9 Mon Sep 17 00:00:00 2001 From: roalz Date: Mon, 22 Aug 2016 16:34:18 +0200 Subject: [PATCH 5/5] Update index.html.haml %pre.changelog= File.read("CHANGELOG.md") instead of %pre.changelog= File.read(File.expand_path("../../CHANGELOG.md", __FILE__)) --- source/it-IT/0.3.0/index.html.haml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/it-IT/0.3.0/index.html.haml b/source/it-IT/0.3.0/index.html.haml index 4a37976..543a6fe 100644 --- a/source/it-IT/0.3.0/index.html.haml +++ b/source/it-IT/0.3.0/index.html.haml @@ -13,7 +13,7 @@ language: it-IT Un change log è un file che contiene una lista curata e ordinata cronologicamente delle modifiche degne di nota per ogni versione di un progetto. -%pre.changelog= File.read(File.expand_path("../../CHANGELOG.md", __FILE__)) +%pre.changelog= File.read("CHANGELOG.md") :markdown ### A cosa serve un change log?