Fixed some Italian typos. (#205)

Author: fabiosoggia

docs/it/data-flow.md

@@ -1,6 +1,6 @@
 # Flusso dei Dati
 
-Costruiamo un semplice contatore tramite Vuex per avere una visione migliore su come i dati siano scambiati tra i vari componenti. Si noti che questo esempio è un estremizzazione per spiegare alcuni concetti chiavi, Vuex non è utile per questo tipo di applicazioni molto semplici.
+Costruiamo un semplice contatore tramite Vuex per avere una visione migliore su come i dati siano scambiati tra i vari componenti. Si noti che questo esempio è un'estremizzazione per spiegare alcuni concetti chiavi, Vuex non è utile per questo tipo di applicazioni molto semplici.
 
 ### Lo Store
 

docs/it/forms.md

@@ -8,7 +8,7 @@ Quando si utilizza Vuex in modalità strict, può risultare difficile utilizzare
 
 Presupponendo che `obj` sia una proprietà derivata che restituisce un oggetto dallo store, avremmo una situazione dove `v-model` cerca di mutare direttamente `obj.message` quando l'utente modifica l'input. In modalità strict questo solleverebbe un errore a causa di una mutazione non avvenuta internamente ad una mutation di Vuex.
 
-Un modo per risolvere questo conflitto in Vuex è quello di legare l `<input>` ad una chiamata che si riferisce ad un'azione. L'input si lega tramite `input` oppure l'evento `change`:
+Un modo per risolvere questo conflitto in Vuex è quello di legare l'`<input>` ad una chiamata che si riferisce ad un'azione. L'input si lega tramite `input` oppure l'evento `change`:
 
 ``` html
 <input :value="message" @input="updateMessage">
@@ -38,4 +38,4 @@ mutations: {
 }
 ```
 
-Questo approccio rendere l'utilizzo di `v-model` leggermente più complesso ma è un trade-off necessario per rendere il vincolo tra l'input e lo stato tracciabile. Detto questo è giusto ricordare che Vuex non obbliga l'inserimento di tutti gli stati dentro ad uno store, se avete bisogno di tracciare degli stati che sono specifici di un solo componente è possibile farlo benissimo fuori dallo store di Vuex.
+Questo approccio rende l'utilizzo di `v-model` leggermente più complesso ma è un trade-off necessario per rendere il vincolo tra l'input e lo stato tracciabile. Detto questo è giusto ricordare che Vuex non obbliga l'inserimento di tutti gli stati dentro ad uno store, se avete bisogno di tracciare degli stati che sono specifici di un solo componente è possibile farlo benissimo fuori dallo store di Vuex.

docs/it/getting-started.md

@@ -8,7 +8,7 @@ Al centro di qualsiasi applicazione che utilizza Vuex si trova lo **store**. Uno
 
 ### Lo Store più Semplice
 
-> **NOTA:** Nel cosrso della guida utilizzeremo la sintassi JavaScript che si riferisce a `ES2015` se ancora non siete al corrente degli aggiornamenti [aggiornatevi al riguardo](https://babeljs.io/docs/learn-es2015/)!
+> **NOTA:** Nel corso della guida utilizzeremo la sintassi JavaScript che si riferisce a `ES2015` se ancora non siete al corrente degli aggiornamenti [aggiornatevi al riguardo](https://babeljs.io/docs/learn-es2015/)!
 Questa documentazione, insoltre, assume che voi siate al corrente con i concetti discussi nel capitolo: [Costruire un'Applicazione scalabile](http://it.vuejs.org/guide/application.html).
 
 Creare uno Store in Vuex è un processo abbastanza semplice, si inizia con lo stato iniziale e qualche mutations:
@@ -32,7 +32,7 @@ const store = new Vuex.Store({
 })
 ```
 
-Ora potrete accedere all oggetto stato tramite `store.state` ed eventualmente attivare mutazioni, per esempio sul nome:
+Ora potrete accedere all'oggetto stato tramite `store.state` ed eventualmente attivare mutazioni, per esempio sul nome:
 
 ``` js
 store.dispatch('INCREMENT')
@@ -49,6 +49,6 @@ store.dispatch({
 })
 ```
 
-Di nuovo, il motivo per il quale stiamo effettuando il dispatch invece di cambiare lo stato tramite `store.state.count` è perchè vogliamo esplicitamente tenere traccia del cambiamento in se. Questa semplice convenzione rende le nostre intenzioni più esplicite, aiutando anche a capire perchè cambiamo lo stato in determinati punti del nostro codice. In aggiunta, questo ci permette di implementare strumenti per tenere traccia delle mutazioni, salvarne una copia o fare anche debuggin trasversale.
+Di nuovo, il motivo per il quale stiamo effettuando il dispatch invece di cambiare lo stato tramite `store.state.count` è perchè vogliamo esplicitamente tenere traccia del cambiamento in se. Questa semplice convenzione rende le nostre intenzioni più esplicite, aiutando anche a capire perchè cambiamo lo stato in determinati punti del nostro codice. In aggiunta, questo ci permette di implementare strumenti per tenere traccia delle mutazioni, salvarne una copia o fare anche debugging trasversale.
 
-Ovviamente questo è un esempio molto semplice di come funziona Vuex e la centralizzazione degli stati. Più avanti discuteremo di alcuni concetti in dettagli come: [Stati](state.md), [Mutazioni](mutations.md) ed [Azioni](actions.md).
+Ovviamente questo è un esempio molto semplice di come funziona Vuex e la centralizzazione degli stati. Più avanti discuteremo di alcuni concetti in dettaglio come: [Stati](state.md), [Mutazioni](mutations.md) ed [Azioni](actions.md).

docs/it/mutations.md

@@ -26,9 +26,9 @@ Non è possibile richiamare un handler direttamente. Bisogna registrarlo tramite
 store.dispatch('INCREMENT')
 ```
 
-### Disptach con Argomenti
+### Dispatch con Argomenti
 
-E' possibile passare gli argomenti alla mutation:
+E' possibile passare degli argomenti alla mutation:
 
 ``` js
 // ...
@@ -103,7 +103,7 @@ export function start(store, options = {}) {
 Dato che lo stato di Store in Vuex segue la filosofia "reattiva" di Vue, quando mutiamo uno stato, tutti i componenti che osservano tale stato riceveranno l'aggiornamento in modo automatico.
 Questo significa che anche le mutation hanno bisogno di qualche precauzione:
 
-1. E' preferibile inizializzare ogni stato all interno dello store.
+1. E' preferibile inizializzare ogni stato all'interno dello store.
 
 2. Quando si aggiunge una proprietà ad un oggetto è consigliato:
 
@@ -142,7 +142,7 @@ const store = new Vuex.Store({
 })
 ```
 
-L'utilizzo delle costanti è altamente consigliato soprattutto quando si divide in più moduli un'applicazione di larga scala. Tutta via non c'è nessuna regola che vi obbliga ad utilizzare tale sintassi se non vi piace.
+L'utilizzo delle costanti è altamente consigliato soprattutto quando si divide in più moduli un'applicazione di larga scala. Tuttavia non c'è nessuna regola che vi obbliga ad utilizzare tale sintassi se non vi piace.
 
 ### Le Mutation devono essere Sincrone
 
@@ -162,4 +162,4 @@ Ora immaginate di dover debuggare l'applicazione e guardate il log delle mutatio
 
 ### Sulle Azioni
 
-Le mutazioni di stato combinate con eventi asincroni possono portare difficoltà nel capire che cosa succede in un determinato momento. Per sempio se chiamate due metodi, entrambi implementano internamente delle chiamate asincrone, come potete stabilire l'ordine di chiamata? Ecco perchè dev'essere chiaro il motivo per il quale qualsiasi tipo di operazione asincrona dev'essere fatto tramite le [Azioni](actions.md)
+Le mutazioni di stato combinate con eventi asincroni possono portare difficoltà nel capire che cosa succede in un determinato momento. Per esempio se chiamate due metodi, entrambi implementano internamente delle chiamate asincrone, come potete stabilire l'ordine di chiamata? Ecco perchè dev'essere chiaro il motivo per il quale qualsiasi tipo di operazione asincrona dev'essere fatto tramite le [Azioni](actions.md)

docs/it/state.md

@@ -100,7 +100,7 @@ computed: {
 }
 ```
 
-### I Getter posso restituire Stati Derivati
+### I Getter possono restituire Stati Derivati
 
 Se consideriamo che i getter di Vuex dietro le quinte sono delle proprietà derivate, allora possiamo intuire che è possibile sfruttare alcune proprietà di quest'ultime per restituire uno stato più eleborato.
 Per esempio, si consideri che lo stato ha un array di `messaggi` contenente tutti i messaggi, ed un `currentThreadID` che rappresenta il thread corrente visualizzato dall utente.

docs/it/strict.md

@@ -13,7 +13,7 @@ Quando si è in modalità strict, ogni volta che Vuex viene mutato al di fuori d
 
 ### Sviluppo vs Produzione
 
-**Non abilutate la modalità strict quando pubblicate il progetto in produzione** La modalità strict esegue una scansione approfondita di ogni mutation per capire i cambiamenti effettuati sugli stati dello store - in produzione questo portrebbe a dei problemi di prestazioni.
+**Non abilitate la modalità strict quando pubblicate il progetto in produzione** La modalità strict esegue una scansione approfondita di ogni mutation per capire i cambiamenti effettuati sugli stati dello store - in produzione questo porterebbe a dei problemi di prestazioni.
 
 Come sui middleware anche qui possiamo automatizzare il processo di abilitazione/disabilitazione tramite gli strumenti di build:
 

docs/it/testing.md

@@ -47,7 +47,7 @@ describe('mutations', () => {
 
 ### Testare le Action
 
-Le Action possono essere più complesse da testate dato che possono contenere chiamate ad API esterne a Vuex. Quando si testano le action, si dovrà fare uso, nella maggior parte dei casi, di un sistema di mocking - per esempio nel caso volessimo chiamare delle API ad un servizio di terze parti
+Le Action possono essere più complesse da testate dato che possono contenere chiamate ad API esterne a Vuex. Quando si testano le action, si dovrà fare uso, nella maggior parte dei casi, di un sistema di mocking - per esempio nel caso volessimo chiamare delle API ad un servizio di terze parti.
 Per effettuare il mocking delle dipendenze, si può utilizzare il comodo sistema di [inject-loader](https://github.com/plasticine/inject-loader) assieme a WebPack.
 
 Esempio su una Action asincrona:
@@ -156,7 +156,7 @@ mocha test-bundle.js
 #### Testare nel Browser
 
 1. Installare `mocha-loader`
-2. Cambiare l `entry` dalla configurazione Webpack sopra citata in `'mocha!babel!./test.js'`.
+2. Cambiare l'`entry` dalla configurazione Webpack sopra citata in `'mocha!babel!./test.js'`.
 3. Inizializzare `webpack-dev-server` utilizzando la configurazione sopra citata
 4. Andare su `localhost:8080/webpack-dev-server/test-bundle`.
 5. Profit!