From ea378c61aac9d64017a3076a12c5f2a79cd1e9af Mon Sep 17 00:00:00 2001 From: Alberto Moro Date: Wed, 31 May 2023 09:41:08 +0200 Subject: [PATCH] Fixed Italian translation version 1.1.0 (#562) --- source/it-IT/1.1.0/index.html.haml | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/source/it-IT/1.1.0/index.html.haml b/source/it-IT/1.1.0/index.html.haml index 01f1095..8644c5c 100644 --- a/source/it-IT/1.1.0/index.html.haml +++ b/source/it-IT/1.1.0/index.html.haml @@ -30,7 +30,8 @@ version: 1.1.0 %p Per rendere facile agli utilizzatori e contribuenti vedere con precisione quali modifiche - importanti sono state fatte tra ogni release (o versione) del progetto. + importanti sono state fatte tra ogni release (o versione) + del progetto. %h3#who %a.anchor{ href: "#who", aria_hidden: "true" } @@ -106,7 +107,7 @@ version: 1.1.0 Le persone possono vedere quali modifiche si possono aspettare nelle future release. %li Ad una nuova release, si deve solo spostare i cambiamenti della sezione - `"Unreleased"` in una nuova sezione con il corrispettivo numero di versione. + Unreleased in una nuova sezione con il corrispettivo numero di versione. .bad-practices %h3#bad-practices @@ -130,17 +131,20 @@ version: 1.1.0 %p Lo scopo di una voce changelog è quello di documentare le differenze rilevanti, - spesso attraverso commit multipli, per comunicarli in modo chiaro agli utenti finali. + spesso attraverso commit multipli, + per comunicarli in modo chiaro agli utenti finali. %h4#ignoring-deprecations %a.anchor{ href: "#ignoring-deprecations", aria_hidden: "true" } Ignorare le deprecazioni + %p Quando le persone aggiornano da una versione ad un'altra, dovrebbe essere dolorosamente chiaro che qualcosa si romperà. Dovrebbe essere possibile eseguire l'aggiornamento a una versione che elenca le deprecazioni, rimuovere ciò che è deprecato, quindi aggiornare alla versione in cui le deprecazioni diventano rimozioni. + %p Se non fai nient'altro elenca le deprecazioni, le rimozioni e qualsiasi altro cambiamento nel tuo changelog. @@ -167,7 +171,7 @@ version: 1.1.0 %p Un changelog che menziona solo alcune delle modifiche può essere pericoloso - tanto quanto non avere un chengelog. Nonostante molte delle modifiche possano + tanto quanto non avere un changelog. Nonostante molte delle modifiche possano essere irrilevanti - per esempio, nella maggior parte dei casi rimuovere un singolo spazio non necessita di essere documentato - ogni modifica importante deve essere menzionata nel changelog. Applicando in maniera incoerente le modifiche, @@ -196,7 +200,7 @@ version: 1.1.0 %p Questo progetto vuole essere - = link_to "una migliore convenzione per i file changelog.", data.links.changelog + = link_to "una migliore convenzione per i file changelog.", data.links.changelog Per questo motivo osserviamo le migliori pratiche della comunità open source e le portiamo avanti. @@ -224,11 +228,9 @@ version: 1.1.0 %p È una bella iniziativa. #{link_to "Releases", data.links.github_releases} 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 i messaggi dei git tag inserendoli dentro le - note di rilascio. + per rendere semplice i git tags (per esempio il nome del tag v1.0.0) + all'interno di note di rilascio ben dettagliate mediante l'aggiunta manuale delle note di rilascio + oppure è possibile estrarre i messaggi annotati dei git tag e trasformarli in note. %p GitHub Releases crea un changelog non-portable che può essere solo