diff --git a/source/it-IT/1.0.0/index.html.haml b/source/it-IT/1.0.0/index.html.haml
index 546961d..3c38b8e 100644
--- a/source/it-IT/1.0.0/index.html.haml
+++ b/source/it-IT/1.0.0/index.html.haml
@@ -20,7 +20,7 @@ version: 1.0.0
.header
.title
%h1 Tenere un Changelog
- %h2 Non lasciare che i tuoi amici facciano copia incolla dei git logs nei changelogs.
+ %h2 Non lasciare che i tuoi amici facciano copia incolla dei git logs nei changelog.
= link_to changelog do
Versione
@@ -34,7 +34,7 @@ version: 1.0.0
Cos'è un changelog?
%p
- Un change log è un file che contiene una lista curata e ordinata cronologicamente
+ Un changelog è un file che contiene una lista curata e ordinata cronologicamente
delle modifiche degne di nota per ogni versione di un progetto.
%h3#why
@@ -124,14 +124,14 @@ version: 1.0.0
.bad-practices
%h3#bad-practices
%a.anchor{ href: "#bad-practices", aria_hidden: "true" }
- I changelogs possono essere cattivi?
+ I changelog possono essere cattivi?
%p Si. Ecco alcuni modi in cui possono essere meno utili.
%h4#log-diffs
%a.anchor{ href: "#log-diffs", aria_hidden: "true" }
Commit log diffs
%p
- Usare commit log diffs al posto dei changelogs è una brutta idea: contengono solo cose superflue.
+ Usare commit log diffs al posto dei changelog è una brutta idea: contengono solo cose superflue.
Come come merge commits, commits con titoli oscuri,
modifiche della documentazione, etc.
@@ -147,77 +147,77 @@ version: 1.0.0
%a.anchor{ href: "#ignoring-deprecations", aria_hidden: "true" }
Ignorare le Deprecazioni
%p
- When people upgrade from one version to another, it should be
- painfully clear when something will break. It should be possible to
- upgrade to a version that lists deprecations, remove what's
- deprecated, then upgrade to the version where the deprecations
- become removals.
+ Quando le persone aggiornano da una versione ad un'altra,
+ dovrebbe essere dolorosamente chiaro quando qualcosa si romperà.
+ Dovrebbe essere possibile eseguire l'aggiornamento a una versione
+ che elenca le deprecazioni, rimuove ciò che è deprecato, quindi
+ aggiorna alla versione in cui le deprecazioni diventano rimozioni.
%p
- If you do nothing else, list deprecations, removals, and any
- breaking changes in your changelog.
+ Se non fai nient'altro elenca le deprecazioni, le rimozioni e
+ qualsiasi altro cambiamento nel tuo changelog.
%h4#confusing-dates
%a.anchor{ href: "#confusing-dates", aria_hidden: "true" }
- Confusing Dates
+ Confusione delle date
%p
- In the U.S., people put the month first (06-02-2012
for
- June 2nd, 2012), 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 #{link_to "ISO standard", iso}. Thus, it is the
- recommended date format for changelogs.
+ Negli Stati Uniti si mette prima il mese nelle date (06-02-2012
sta per
+ il 2 Giugno 2012), 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 #{link_to "ISO standard", iso}.
+ Per tutti questi motivi, è il formato di date raccomandato per i changelog.
%aside
- There’s more. Help me collect these antipatterns by
- = link_to "opening an issue", issues
- or a pull request.
+ C'è di più. Aiutatemi a collezionare questi anti-modelli
+ = link_to "aprendo un issue", issues
+ o una pull request.
.frequently-asked-questions
%h3#frequently-asked-questions
%a.anchor{ href: "#frequently-asked-questions", aria_hidden: "true" }
- Frequently Asked Questions
+ Domande frequenti
%h4#standard
%a.anchor{ href: "#standard", aria_hidden: "true" }
- Is there a standard changelog format?
+ Esiste un formato standard per i changelog?
%p
- Not really. There's the GNU changelog style guide, or the two-
- paragraph-long GNU NEWS file "guideline". Both are inadequate or
- insufficient.
+ Non esattamente. Esistono le linee guida GNU sullo stile dei changelog, oppure
+ i due lunghi paragrafi nel documento di GNU NEWS denominato "guideline". Entrambe
+ sono inadeguate o insufficienti.
%p
- This project aims to be
- = link_to "a better changelog convention.", changelog
- It comes from observing good practices in the open source
- community and gathering them.
+ Questo progetto vuole essere
+ = link_to "una migliore convenzione per i file changelog.", changelog
+ Per questo motivo osserviamo le migliori pratiche della comunità open source
+ e le portiamo avanti.
%p
- Healthy criticism, discussion and suggestions for improvements
- = link_to "are welcome.", issues
+ Critiche, discussioni e suggerimenti per migliorare
+ = link_to "sono ben accetti.", issues
%h4#filename
%a.anchor{ href: "#filename", aria_hidden: "true" }
- What should the changelog file be named?
+ Come si dovrebbe chiamare il file di changelog?
%p
- Call it CHANGELOG.md
. Some projects use
- HISTORY
, NEWS
or RELEASES
.
+ Chiamalo CHANGELOG.md
. Alcuni progetti usano anche
+ HISTORY
, NEWS
o RELEASES
.
%p
- While it's easy to think that the name of your changelog file
- doesn't matter that much, why make it harder for your end users to
- consistently find notable changes?
+ Mentre è facile pensare che il nome del tuo file changelog
+ non sia poi così importante, perchè non rendere facile la
+ vita ai tuoi utenti, usando sempre lo stesso nome?
%h4#github-releases
%a.anchor{ href: "#github-releases", aria_hidden: "true" }
- What about GitHub Releases?
+ Cosa dire delle GitHub Releases?
%p
- It's a great initiative. #{link_to "Releases", ghr} can be used to
- turn simple git tags (for example a tag named v1.0.0
)
- into rich release notes by manually adding release notes or it can
- pull annotated git tag messages and turn them into notes.
+ È una bella iniziativa. #{link_to "Releases", ghr} può essere usato
+ per rendere semplice i git tags (per esempio il nome del tag v1.0.0
)
+ All'interno di note di rilascio ben dettagliate si possono aggiungere le note manualmente oppure è possibile
+ utilizzare le note dei messaggi dei git tag inserendole dentro nelle note di rilascio.
+ j
%p
GitHub Releases create a non-portable changelog that can only be
displayed to users within the context of GitHub. It's possible to