diff --git a/en/11/05.md b/en/11/05.md
index 57d175183..0aac5ad49 100644
--- a/en/11/05.md
+++ b/en/11/05.md
@@ -58,7 +58,7 @@ Once we specified the contract we wanted to test using `artifacts.require`, _Tru
 Besides these bits of information, `result` is going to be giving us several other useful details about the transaction:
 
 - `result.tx`: the transaction hash
-- `result.receipt`: an object containing the transaction receipt. If `result.receipt.status` is equal to ` true` it means that the transaction was successful. Otherwise, it means that the transaction failed.
+- `result.receipt`: an object containing the transaction receipt. If `result.receipt.status` is equal to `true` it means that the transaction was successful. Otherwise, it means that the transaction failed.
 
 >Note: Note that logs can also be used as a much cheaper option to store data. The downside is that they can't be accessed from within the smart contract itself.
 
diff --git a/es/6/01.md b/es/6/01.md
index 74a51cd3d..5fb1926ec 100644
--- a/es/6/01.md
+++ b/es/6/01.md
@@ -433,7 +433,7 @@ Recuerda, que la red de Ethereum está formada por nodos, cada uno de los cuales
 Los nodos de Ethereum solamente hablan un idioma llamado **_JSON-RPC_**, cuyo lenguaje es bastante difícil de leer para un humano. Una consulta para decirle al nodo que quieres llamar una función en un Contrato Inteligente es algo así:
 
 ```
-// ¡Y esque escribiendo nuestro contrato así tardaríamos una eternidad!
+// ¡Y es que escribiendo nuestro contrato así tardaríamos una eternidad!
 // Scroll right ==>
 {"jsonrpc":"2.0","method":"eth_sendTransaction","params":[{"from":"0xb60e8dd61c5d32be8058bb8eb970870f07233155","to":"0xd46e8dd67c5d32be8058bb8eb970870f07244567","gas":"0x76c0","gasPrice":"0x9184e72a000","value":"0x9184e72a","data":"0xd46e8dd67c5d32be8d46e8dd67c5d32be8058bb8eb970870f072445675058bb8eb970870f072445675"}],"id":1}
 ```
diff --git a/es/6/02.md b/es/6/02.md
index 55f606bcd..a70855f4d 100644
--- a/es/6/02.md
+++ b/es/6/02.md
@@ -435,7 +435,7 @@ material:
       </html>
 ---
 
-Estupendo! Ahora que ya tenemos Web3.js en nuestro proyecto, vamos a inicializarlo y hablar de la blockchain.
+¡Estupendo! Ahora que ya tenemos Web3.js en nuestro proyecto, vamos a inicializarlo y hablar de la blockchain.
 
 Lo primero que necesitamos, es un **_Web3 Provider_**.
 
@@ -445,15 +445,15 @@ Podrías "hostear" tu propio nodo Ethereum como proveedor. Sin embargo, hay un s
 
 ## Infura
 
-<a href="https://infura.io/" target=_blank>Infura</a> es un servicio que mantiene un conjunto de nodos Ethereum con una capa de almacenamiento en caché para lecturas rápidas, el cual puedes acceder de forma gratuita a través de su API. Usando Infura comno proveedor, puedes enviar y recibir mensajes de manera confiable desde/hacia la blockchain de Ethereum sin necesidad de mantener y configurar tu propio nodo.
+<a href="https://infura.io/" target=_blank>Infura</a> es un servicio que mantiene un conjunto de nodos Ethereum con una capa de almacenamiento en caché para lecturas rápidas, el cual puedes acceder de forma gratuita a través de su API. Usando Infura como proveedor, puedes enviar y recibir mensajes de manera confiable desde/hacia la blockchain de Ethereum sin necesidad de mantener y configurar tu propio nodo.
 En el siguiente ejemplo, se muestra como se puede configurar Web3 para usar Infura como proveedor Web3:
 ```
 var web3 = new Web3(new Web3.providers.WebsocketProvider("wss://mainnet.infura.io/ws"));
 ```
 Sin embargo, dado que muchas personas serán usuarios de nuestra DApp — y estos usuarios no solo van a leer la blockchain sino también escribir en ella — vamos a necesitar una forma para que estos usuarios puedan firmar diversas transacciones con su llave privada.
 > Nota: Ethereum (y las Blockchains en general) usan una llave pública/privada para firmar de forma digital las transacciones. De esta manera si cambio algunos datos de la Blockchain, puedo **demostrar** a través de mi llave pública que fui yo quien lo firmó — pero como nadie sabe mi llave privada, nadie puede falsificar una transacción en mi nombre.
-La criptografía es complicada, así que a menos que seas un experto en seguridad y realmente sepas lo que estás haciendo, probablemente no sea una buena idea tratar de administrar manuealmente las claves privadas de los usuarios en el front-end de nuestra aplicación.
-Per afortunadamente no necesitamos hacerlo — hoy en día ya hay servicios que manejan estas llaves por nosotros. El más popular de estos es **_Metamask_**.
+La criptografía es complicada, así que a menos que seas un experto en seguridad y realmente sepas lo que estás haciendo, probablemente no sea una buena idea tratar de administrar manualmente las claves privadas de los usuarios en el front-end de nuestra aplicación.
+Pero afortunadamente no necesitamos hacerlo — hoy en día ya hay servicios que manejan estas llaves por nosotros. El más popular de estos es **_Metamask_**.
 
 ## Metamask
 
@@ -478,8 +478,8 @@ window.addEventListener('load', function() {
   startApp()
 })
 ```
-Puedes usar este código en todas tus aplicaciones que exijan tener instado Metamask.
-> Nota: Hay otros programas de administración de claves privadas que sus usuarios podrían estar usando además de MetaMask, como por ejemplo el navegador web **Mist**. No obstante, todos implementan un patrón de inyección de la variable `web3`, por lo que el método que describimos aquí para detectar el proveedor web3 del usuario también funcionará para estos.
+Puedes usar este código en todas tus aplicaciones que exijan tener instalado Metamask.
+> Nota: Hay otros programas de administración de claves privadas que sus usuarios podrían estar usando además de MetaMask, como por ejemplo el navegador web **Mist**. No obstante, todos implementan un patrón de inyección de la variable `web3`, por lo que el método que describimos aquí para detectar el proveedor web3 del usuario también funcionará para éstos.
 ## Póngalo a prueba
 Hemos creado algunas etiquetas de script antes del cierre `</body>` en tu archivo HTML. Podemos escribir tu código de JavaScript para esta lección aquí.
 1. Dirígete arriba y copia/pega la plantilla de código para detectar si nuestros usuarios tienen instalado Metamask. Es el bloque que comienza con `window.addEventListener`.
diff --git a/es/6/03.md b/es/6/03.md
index 74acbf4d7..1244b4753 100644
--- a/es/6/03.md
+++ b/es/6/03.md
@@ -912,7 +912,7 @@ material:
 
 Ahora que ya hemos inicializado Web3.js con el proveedor Web3 de MetaMask, vamos a configurarlo para hablar con nuestro contrato inteligente.
 
-Web3.js va a necesitar dos cosas para poder hablar con nuestro contrato inteligente: su **_address_** (dirección y su **_ABI_**).
+Web3.js va a necesitar dos cosas para poder hablar con nuestro contrato inteligente: su **_address_** (dirección) y su **_ABI_**).
 
 ## Dirección del contrato
 
@@ -931,7 +931,7 @@ Cuando compilas tu contrato para implementarlo en Ethereum (que cubriremos en la
 
 Como aún no hemos cubierto el tema de la implementación y de momento no lo vamos a hacer, para esta lección, hemos compilado el ABI para ti y lo hemos puesto en un archivo llamado `cryptozombies_abi.js`, almacenado en una variable llamada `cryptoZombiesABI`.
 
-Si incluimos `cryptozombies_abi.js` en nuestro proyecto, vamos a ser capaces de accceder a nuestro CryptoZombies ABI usando esta variable.
+Si incluimos `cryptozombies_abi.js` en nuestro proyecto, vamos a ser capaces de acceder a nuestro CryptoZombies ABI usando esta variable.
 
 ## Instanciando un Contrato Web.js
 
@@ -952,4 +952,4 @@ var myContract = new web3js.eth.Contract(myABI, myContractAddress);
 
 4. Lo primero que debe hacer `startApp()` es declarar una `var` llamada `cryptoZombiesAddress` y asígnale su valor al string `"YOUR_CONTRACT_ADDRESS"` (esta es la dirección del contrato de CryptoZombies en la mainnet).
 
-5. Finalmente, vamos a inicializar nuestro contrarto. Establezca `cryptoZombies` igual a un nuevo` web3js.eth.Contract` como lo hicimos en el código de ejemplo anterior. (Usando `cryptoZombiesABI`, que se importa con nuestra etiqueta de script, y `cryptoZombiesAddress` desde arriba).
+5. Finalmente, vamos a inicializar nuestro contrarto. Establezca `cryptoZombies` igual a un nuevo `web3js.eth.Contract` como lo hicimos en el código de ejemplo anterior. (Usando `cryptoZombiesABI`, que se importa con nuestra etiqueta de script, y `cryptoZombiesAddress` desde arriba).
diff --git a/es/6/04.md b/es/6/04.md
index cff4e5f51..9af01ae12 100644
--- a/es/6/04.md
+++ b/es/6/04.md
@@ -1,5 +1,5 @@
 ---
-title: LLamando a las funciones de nuestro Contrato
+title: Llamando a las funciones de nuestro Contrato
 actions: ['checkAnswer', 'hints']
 requireLogin: true
 material:
@@ -522,7 +522,7 @@ En Solidity, cuando tú declaras una variable `public`, automáticamente se crea
 
 Así es como escribiríamos una función de JavaScript en nuestro front-end que tomaría una identificación de zombie, consultaría nuestro contrato para ese zombie, y devolvería el resultado:
 
-> Nota: Todos los ejemplos de código que estamos usando en esta lección usan la **versión 1.0** de Web3.js, que usa promesas en lugar de devoluciones. Muchos otros tutoriales que verás en internet usarán una versión anterior de Web3.js. La sintaxis ha cambiado mucho con la versión 1.0, así que si estás copiando el código de otros tutoriales, asegúrate de que estén usando la misma versión que tu.
+> Nota: Todos los ejemplos de código que estamos usando en esta lección usan la **versión 1.0** de Web3.js, que usa promesas en lugar de devoluciones. Muchos otros tutoriales que verás en internet usarán una versión anterior de Web3.js. La sintaxis ha cambiado mucho con la versión 1.0, así que si estás copiando el código de otros tutoriales, asegúrate de que estén usando la misma versión que tú.
 ```
 function getZombieDetails(id) {
   return cryptoZombies.methods.zombies(id).call()
@@ -551,7 +551,7 @@ Una vez que la promesa se resuelva (lo que significa que recibimos una respuesta
   "level": "9999",
   "readyTime": "1522498671",
   "winCount": "999999999",
-  "lossCount": "0" // Obviously.
+  "lossCount": "0" // Obviamente.
 }
 ```
 
diff --git a/es/6/05.md b/es/6/05.md
index b6a366ec7..ba4a66f03 100644
--- a/es/6/05.md
+++ b/es/6/05.md
@@ -503,7 +503,7 @@ Ahora juntemos algunas piezas — digamos que queremos que la página de inicio
 
 Obviamente, primero necesitaríamos usar nuestra función `getZombiesByOwner(owner)` para buscar todas las IDs de todos los zombies que los usuarios actuales tienen.
 
-Pero nuestro contrato Solidity espera que `owner` usa una Solidity `address`. ¿Cómo podemos saber la dirección del usuario que usa nuestra aplicación?
+Pero nuestro contrato Solidity espera que `owner` sea una Solidity `address`. ¿Cómo podemos saber la dirección del usuario que usa nuestra aplicación?
 
 ## Obteniendo la cuenta de los usuarios de MetaMask
 
diff --git a/es/6/06.md b/es/6/06.md
index 26d752eb2..8ab369c07 100644
--- a/es/6/06.md
+++ b/es/6/06.md
@@ -531,7 +531,7 @@ material:
       </html>
 ---
 
-Este tutorial no estaría completado si no te enseñamos cómo mostrar realmente los datos que obtiene el contrato.
+Este tutorial no estaría completo si no te enseñamos cómo mostrar realmente los datos que obtiene el contrato.
 
 Sin embargo, de forma realista, querrás utilizar un marco front-end como React or Vue.js en tu aplicación web, ya que hacen que tu vida sea mucho más fácil como desarrollador de front-ends. Pero cubrir React o Vue.js está fuera del alcance de este tutorial — eso acabaría siendo un tutorial completo con múltiples lecciones en sí mismo.
 
diff --git a/es/6/07.md b/es/6/07.md
index 73531ee04..f21fc3913 100644
--- a/es/6/07.md
+++ b/es/6/07.md
@@ -586,7 +586,7 @@ material:
       </html>
 ---
 
-Increíble! Ahora nuestra UI va a detectar la cuenta MetaMask del usuario, y automáticamente mostrar por pantalla su ejército zombie en la página de inicio.
+¡Increíble! Ahora nuestra UI va a detectar la cuenta MetaMask del usuario, y automáticamente mostrar por pantalla su ejército zombie en la página de inicio.
 
 Ahora veamos el uso de las funciones `send` para cambiar los datos en nuestro contrato inteligente.
 
@@ -650,7 +650,7 @@ Hemos añadido un `div` con la ID `txStatus` — de esta manera podemos usar est
 
 1. Abajo de `displayZombies`, copia/pega el código de la función `createRandomZombie` situado arriba.
 
-2. Let's implement another function: `feedOnKitty`.
+2. Vamos a implementar otra función: `feedOnKitty`.
 
   La lógica para llamar `feedOnKitty` será casi idéntica — enviaremos una transacción que llame a la función, y una transacción exitosa resulta en un nuevo zombie creado para nosotros, así que querremos volver a dibujar la IU después de que sea exitosa.
 
diff --git a/es/6/08.md b/es/6/08.md
index de44d86c7..4f84cbbda 100644
--- a/es/6/08.md
+++ b/es/6/08.md
@@ -1,5 +1,5 @@
 ---
-title: LLamando funciones Payables
+title: Llamando funciones Payables
 actions: ['checkAnswer', 'hints']
 requireLogin: true
 material:
@@ -622,7 +622,7 @@ material:
       </html>
 ---
 
-La lógica para `attack`,` changeName`, y `changeDna` será extremadamente similar, entonces son triviales de implementar y no vamos a perder tiempo codificándolos en esta lección.
+La lógica para `attack`, `changeName`, y `changeDna` será extremadamente similar, por lo que son triviales de implementar y no vamos a perder tiempo codificándolas en esta lección.
 
 > De hecho, ya hay mucha lógica repetitiva en cada una de estas funciones, por lo que probablemente tendría sentido refactorizar y poner el código común en su propia función. (Y usar un sistema de plantillas para los mensajes `txStatus` — ¡ya estamos viendo cuánto más limpias serían las cosas con un framework como Vue.js!)
 Veamos otro tipo de función que requiere un tratamiento especial en Web3.js — funciones `payable`.
@@ -642,7 +642,7 @@ La forma de enviar Ether junto con una función es simple, con una advertencia:
 
 ## ¿Qué es un Wei?
 
-Un `wei` es la sub-unidad más pequeña del Ether — hay 10^18 `wei`s en un `ether`.
+Un `wei` es la subunidad más pequeña del Ether — hay 10^18 `wei`s en un `ether`.
 
 Eso es un montón de ceros para contar — pero afortunadamente Web3.js tiene una utilidad de conversión que hace esto por nosotros.
 
diff --git a/es/6/09.md b/es/6/09.md
index 17572d535..b65227f7d 100644
--- a/es/6/09.md
+++ b/es/6/09.md
@@ -684,7 +684,7 @@ cryptoZombies.events.Transfer({ filter: { _to: userAccount } })
 }).on("error", console.error);
 ```
 
-Como puedes ver, el uso de los campos `events` e` indexed` puede ser una práctica bastante útil para escuchar los cambios en tu contrato y reflejarlos en el front-end de tu aplicación.
+Como puedes ver, el uso de los campos `events` e `indexed` puede ser una práctica bastante útil para escuchar los cambios en tu contrato y reflejarlos en el front-end de tu aplicación.
 
 ## Consultando eventos pasados
 
diff --git a/es/6/10-wrappingitup.md b/es/6/10-wrappingitup.md
index 1aa94f526..f05eb7175 100644
--- a/es/6/10-wrappingitup.md
+++ b/es/6/10-wrappingitup.md
@@ -13,7 +13,7 @@ material:
 
 ¡Felicidades! Has escrito con éxito tu primer front-end Web3.js que interactúa con tu contrato inteligente.
 
-¡Como recompensa, obtienes tu propio zombie `The Phantom of Web3`! Nivel 3.0 (para Web 3.0 😉), completo con máscara de zorro. Miralo hacia la derecha.
+¡Como recompensa, obtienes tu propio zombie `The Phantom of Web3`! Nivel 3.0 (para Web 3.0 😉), completo con máscara de zorro. Puedes verlo a la derecha.
 
 ## Siguientes pasos
 
diff --git a/fa/11/05.md b/fa/11/05.md
index 3253a9b9d..7a6076d19 100644
--- a/fa/11/05.md
+++ b/fa/11/05.md
@@ -58,7 +58,7 @@ Once we specified the contract we wanted to test using `artifacts.require`, _Tru
 Besides these bits of information, `result` is going to be giving us several other useful details about the transaction:
 
 - `result.tx`: the transaction hash
-- `result.receipt`: an object containing the transaction receipt. If `result.receipt.status` is equal to ` true` it means that the transaction was successful. Otherwise, it means that the transaction failed.
+- `result.receipt`: an object containing the transaction receipt. If `result.receipt.status` is equal to `true` it means that the transaction was successful. Otherwise, it means that the transaction failed.
 
 >Note: Note that logs can also be used as a much cheaper option to store data. The downside is that they can't be accessed from within the smart contract itself.
 
diff --git a/fr/1/datatypes.md b/fr/1/datatypes.md
index cf407984d..dd4acc06b 100644
--- a/fr/1/datatypes.md
+++ b/fr/1/datatypes.md
@@ -41,7 +41,7 @@ Dans cet exemple de contrat, nous avons créé un `uint` appelé `myUnsignedInte
 
 Le type de données `uint` est un entier non signé, cela veut dire que **sa valeur doit être non négative**. Il existe aussi un type de données `int` pour les entiers signés.
 
-> Remarque: En Solidity, `uint` est en fait un alias pour` uint256`, un entier non signé de 256 bits. Vous pouvez déclarer des uints avec moins de bits - `uint8`,` uint16`, `uint32`, etc. Mais en général il est plus simple d'utiliser `uint` sauf dans des cas spécifiques que nous aborderons dans les leçons suivantes.
+> Remarque: En Solidity, `uint` est en fait un alias pour `uint256`, un entier non signé de 256 bits. Vous pouvez déclarer des uints avec moins de bits - `uint8`, `uint16`, `uint32`, etc. Mais en général il est plus simple d'utiliser `uint` sauf dans des cas spécifiques que nous aborderons dans les leçons suivantes.
 
 
 # A votre tour
diff --git a/it/1/datatypes.md b/it/1/datatypes.md
index c828bfc45..3441b309b 100644
--- a/it/1/datatypes.md
+++ b/it/1/datatypes.md
@@ -35,7 +35,7 @@ contract Example {
 }
 ```
 
-In questo contratto di esempio abbiamo creato un `uint` chiamato` myUnsignedInteger` e lo abbiamo impostato su 100.
+In questo contratto di esempio abbiamo creato un `uint` chiamato `myUnsignedInteger` e lo abbiamo impostato su 100.
 
 ## Numeri Interi senza Segno: `uint`
 
@@ -47,4 +47,4 @@ Il tipo di dati `uint` è un numero intero senza segno, nel senso che **il suo v
 
 Il nostro DNA di zombi sarà determinato da un numero di 16 cifre.
 
-Dichiarare un `uint` chiamato` dnaDigits` ed impostarlo uguale a `16`.
+Dichiarare un `uint` chiamato `dnaDigits` ed impostarlo uguale a `16`.
diff --git a/it/1/functions3.md b/it/1/functions3.md
index e51c76aeb..ea01f77c7 100644
--- a/it/1/functions3.md
+++ b/it/1/functions3.md
@@ -95,7 +95,7 @@ Questa funzione non legge nemmeno dallo stato dell'app - il suo valore di ritorn
 
 Vogliamo una funzione di aiuto che generi un numero di DNA casuale da una stringa.
 
-1. Creare una funzione `private` chiamata` _generateRandomDna`. Prenderà un parametro chiamato `_str` (una` string`) e restituirà un `uint`.
+1. Creare una funzione `private` chiamata `_generateRandomDna`. Prenderà un parametro chiamato `_str` (una `string`) e restituirà un `uint`.
 
 2. Questa funzione visualizzerà alcune delle variabili del nostro contratto ma non le modificherà, contrassegnala quindi come `view`.
 
diff --git a/it/1/keccak256.md b/it/1/keccak256.md
index 885418b2c..ebbcab4e5 100644
--- a/it/1/keccak256.md
+++ b/it/1/keccak256.md
@@ -63,7 +63,7 @@ Ethereum ha la funzione hash `keccak256` integrata, che è una versione di SHA3.
 È utile per molti scopi in Ethereum, ma per ora lo useremo solo per la generazione di numeri pseudo-casuali.
 
 
-Importante: `keccak256` prevede un singolo parametro di tipo` byte`. Ciò significa che dobbiamo "impacchettare" tutti i parametri prima di chiamare `keccak256`:
+Importante: `keccak256` prevede un singolo parametro di tipo `byte`. Ciò significa che dobbiamo "impacchettare" tutti i parametri prima di chiamare `keccak256`:
 
 Esempio:
 
@@ -97,6 +97,6 @@ Come vedi sopra `a * b` restituisce un `uint`, ma stavamo provando a memorizzarl
 
 Riempiamo il body della nostra funzione `_generateRandomDna`! Ecco cosa dovrebbe fare:
 
-1. La prima riga di codice dovrebbe prendere l'hash `keccak256` di `abi.encodePacked(_str)` per generare un esadecimale pseudo-casuale, dichiararlo come` uint` ed infine archiviare il risultato in un `uint` chiamato `rand`.
+1. La prima riga di codice dovrebbe prendere l'hash `keccak256` di `abi.encodePacked(_str)` per generare un esadecimale pseudo-casuale, dichiararlo come `uint` ed infine archiviare il risultato in un `uint` chiamato `rand`.
 
 2. Vogliamo che il nostro DNA sia lungo solo 16 cifre (ricordi il nostro `dnaModulus`?). Quindi la seconda riga di codice dovrebbe esssere la `return` del valore `rand` (`%`) `dnaModulus`.
diff --git a/it/1/math.md b/it/1/math.md
index ba3583f9d..4292f32cc 100644
--- a/it/1/math.md
+++ b/it/1/math.md
@@ -44,4 +44,4 @@ uint x = 5 ** 2; // uguale a 5^2 = 25
 
 Per assicurarci che il DNA del nostro Zombi abbia solo 16 caratteri, facciamo un altro `uint` uguale a 10^16. In questo modo possiamo in seguito usare l'operatore modulo `%` per abbreviare un numero intero a 16 cifre.
 
-1. Crea un `uint` chiamato` dnaModulus` ed impostalo uguale a **10 alla potenza di `dnaDigits`**.
+1. Crea un `uint` chiamato `dnaModulus` ed impostalo uguale a **10 alla potenza di `dnaDigits`**.
diff --git a/it/2/3-msgsender.md b/it/2/3-msgsender.md
index e641031a3..653e39e5d 100644
--- a/it/2/3-msgsender.md
+++ b/it/2/3-msgsender.md
@@ -110,7 +110,7 @@ function whatIsMyNumber() public view returns (uint) {
 }
 ```
 
-In questo banale esempio chiunque potrebbe chiamare `setMyNumber` e memorizzare un` uint` nel nostro contratto, che sarebbe legato al loro indirizzo. Quindi quando hanno chiamato `whatIsMyNumber` sono stati restituiti gli `uint` che avevano archiviato.
+In questo banale esempio chiunque potrebbe chiamare `setMyNumber` e memorizzare un `uint` nel nostro contratto, che sarebbe legato al loro indirizzo. Quindi quando hanno chiamato `whatIsMyNumber` sono stati restituiti gli `uint` che avevano archiviato.
 
 L'uso di `msg.sender` ti offre la sicurezza della blockchain di Ethereum - l'unico modo in cui qualcuno può modificare i dati di qualcun altro sarebbe quello di rubare la chiave privata associata al suo indirizzo Ethereum.
 
diff --git a/it/2/5-inheritance.md b/it/2/5-inheritance.md
index d23bbd27e..d1aa0da9e 100644
--- a/it/2/5-inheritance.md
+++ b/it/2/5-inheritance.md
@@ -111,7 +111,7 @@ contract BabyDoge is Doge {
 }
 ```
 
-`BabyDoge` **_eredita_** da `Doge`. Ciò significa che se si compila e si distribuisce `BabyDoge`, esso avrà accesso sia a `catchphrase()` che a `anotherCatchphrase()` (ed a qualsiasi altra funzione pubblica che possiamo definire su` Doge`).
+`BabyDoge` **_eredita_** da `Doge`. Ciò significa che se si compila e si distribuisce `BabyDoge`, esso avrà accesso sia a `catchphrase()` che a `anotherCatchphrase()` (ed a qualsiasi altra funzione pubblica che possiamo definire su `Doge`).
 
 Questo può essere usato per l'eredità logica (come fosse una sottoclasse, un `Gatto` è un `Animale`). Ma può anche essere usato semplicemente per organizzare il tuo codice raggruppando logica simile in contratti diversi.
 
diff --git a/it/3/03-onlyowner.md b/it/3/03-onlyowner.md
index bdb3409cd..3a5e4316f 100644
--- a/it/3/03-onlyowner.md
+++ b/it/3/03-onlyowner.md
@@ -218,7 +218,7 @@ material:
       }
 ---
 
-Ora che il nostro contratto di base `ZombieFactory` eredita da` Ownable`, possiamo usare il modificatore di funzione `onlyOwner` anche in` ZombieFeeding`.
+Ora che il nostro contratto di base `ZombieFactory` eredita da `Ownable`, possiamo usare il modificatore di funzione `onlyOwner` anche in `ZombieFeeding`.
 
 Ciò è dovuto al modo in cui funziona l'eredità del contratto. Ricorda:
 
@@ -325,4 +325,4 @@ Nel caso di `onlyOwner` l'aggiunta di questa funzione di modifica garantirà che
 
 Ora possiamo limitare l'accesso a `setKittyContractAddress` in modo che nessuno, tranne noi, possa modificarlo in futuro.
 
-1. Aggiungi il modificatore `onlyOwner` a` setKittyContractAddress`.
+1. Aggiungi il modificatore `onlyOwner` a `setKittyContractAddress`.
diff --git a/it/3/04-gas.md b/it/3/04-gas.md
index b6e8ce70c..8cbb3d7c5 100644
--- a/it/3/04-gas.md
+++ b/it/3/04-gas.md
@@ -258,7 +258,7 @@ struct MiniMe {
   uint c;
 }
 
-// `mini` costerà meno gas rispetto a` normale` a causa della struttura ad incastro.
+// `mini` costerà meno gas rispetto a `normale` a causa della struttura ad incastro.
 NormalStruct normal = NormalStruct(10, 20, 30);
 MiniMe mini = MiniMe(10, 20, 30); 
 ```
diff --git a/it/3/05-timeunits.md b/it/3/05-timeunits.md
index 23ffbc35d..ab631b95b 100644
--- a/it/3/05-timeunits.md
+++ b/it/3/05-timeunits.md
@@ -246,7 +246,7 @@ function updateTimestamp() public {
 }
 
 // Restituirà `true` se sono trascorsi 5 minuti da quando
-// è stato chiamato` updateTimestamp`, `false` invece se non sono trascorsi 5 minuti
+// è stato chiamato `updateTimestamp`, `false` invece se non sono trascorsi 5 minuti
 function fiveMinutesHavePassed() public view returns (bool) {
   return (now >= (lastUpdated + 5 minutes));
 }
diff --git a/it/3/12-forloops.md b/it/3/12-forloops.md
index edd333c4a..2e2b45958 100644
--- a/it/3/12-forloops.md
+++ b/it/3/12-forloops.md
@@ -303,7 +303,7 @@ Questa funzione restituirà un array con il contenuto `[2, 4, 6, 8, 10]`.
 
 ## Facciamo una prova
 
-Finiamo la nostra funzione `getZombiesByOwner` scrivendo un ciclo` for` che scorre attraverso tutti gli zombi nella nostra DApp, confronta il loro proprietario per vedere se abbiamo una corrispondenza e li inserisce nel nostro array `result` prima di restituirlo.
+Finiamo la nostra funzione `getZombiesByOwner` scrivendo un ciclo `for` che scorre attraverso tutti gli zombi nella nostra DApp, confronta il loro proprietario per vedere se abbiamo una corrispondenza e li inserisce nel nostro array `result` prima di restituirlo.
 
 1. Dichiarare un `uint` chiamato `counter` ed impostarlo uguale a `0`. Useremo questa variabile per tenere traccia dell'indice nel nostro array `result`.
 
diff --git a/it/4/battle-04.md b/it/4/battle-04.md
index 8c410ead8..ceeab4b13 100644
--- a/it/4/battle-04.md
+++ b/it/4/battle-04.md
@@ -339,7 +339,7 @@ Questa è la stessa logica di cui avremo bisogno per la nostra funzione di attac
 
 Torniamo a `zombiefeeding.sol` poiché questo è il primo posto in cui abbiamo usato quella logica. Facciamo un refactor nel suo `modifier`.
 
-1. Creare un `modifier` chiamato `ownerOf`. Ci vorrà 1 argomento: `_zombieId` (a` uint`).
+1. Creare un `modifier` chiamato `ownerOf`. Ci vorrà 1 argomento: `_zombieId` (a `uint`).
 
   Il body dovrebbe `richiedere` che `msg.sender` sia uguale a `zombieToOwner[_zombieId]` per continuare con la funzione. Puoi fare riferimento a `zombiehelper.sol` se non ricordi la sintassi di un `modifier`.
 
diff --git a/it/5/02-erc721-2.md b/it/5/02-erc721-2.md
index 495243dea..a330ae6b5 100644
--- a/it/5/02-erc721-2.md
+++ b/it/5/02-erc721-2.md
@@ -334,7 +334,7 @@ contract SatoshiNakamoto is NickSzabo, HalFinney {
 }
 ```
 
-Come puoi vedere, quando usi l'ereditarietà multipla, devi semplicemente separare i molteplici contratti da cui stai ereditando con una virgola, `,`. In questo caso, il nostro contratto eredita da `NickSzabo` e` HalFinney`.
+Come puoi vedere, quando usi l'ereditarietà multipla, devi semplicemente separare i molteplici contratti da cui stai ereditando con una virgola, `,`. In questo caso, il nostro contratto eredita da `NickSzabo` e `HalFinney`.
 
 Proviamolo.
 
diff --git a/it/5/03-erc721-3.md b/it/5/03-erc721-3.md
index 42f42cf7e..0d8380c7d 100644
--- a/it/5/03-erc721-3.md
+++ b/it/5/03-erc721-3.md
@@ -354,7 +354,7 @@ Questa funzione prende un ID token (nel nostro caso, un ID Zombie) e restituisce
 
 Ancora, questo è molto semplice da implementare, poiché abbiamo già un `mapping` nella nostra DApp che memorizza queste informazioni. Possiamo implementare questa funzione in una riga, solo con un'istruzione `return`.
 
-> Nota: Ricorda, `uint256` equivale a `uint`. Fino ad ora abbiamo usato `uint` nel nostro codice, ma qui stiamo usando` uint256` perché lo abbiamo copiato/incollato dalle specifiche.
+> Nota: Ricorda, `uint256` equivale a `uint`. Fino ad ora abbiamo usato `uint` nel nostro codice, ma qui stiamo usando `uint256` perché lo abbiamo copiato/incollato dalle specifiche.
 
 ## Facciamo una prova
 
diff --git a/it/5/06-erc721-6.md b/it/5/06-erc721-6.md
index 5860f4bc9..b8e88b478 100644
--- a/it/5/06-erc721-6.md
+++ b/it/5/06-erc721-6.md
@@ -358,13 +358,13 @@ Grande! Questa è stata la parte difficile — ora implementare la funzione este
 1. Innanzitutto, vogliamo assicurarci che solo il proprietario o l'indirizzo approvato di un token/zombie possa trasferirlo. Definiamo una mappatura di `zombieApprovals`. Dovrebbe mappare un `uint` ad un `address`.
 In questo modo, quando qualcuno che non è il proprietario richiama `transferFrom` con un `_tokenId`, possiamo usare questa mappatura per cercare rapidamente se è stato approvato a prendere quel token.
 
-2. Quindi, aggiungiamo un'istruzione `request` a` transferFrom`. Controllerà che solo il proprietario o l'indirizzo approvato di un token / zombie possa trasferirlo.
+2. Quindi, aggiungiamo un'istruzione `request` a `transferFrom`. Controllerà che solo il proprietario o l'indirizzo approvato di un token / zombie possa trasferirlo.
 
 3. Infine, non dimenticare di richiamare `_transfer`.
 
 > Nota: verificare che solo il proprietario o l'indirizzo approvato di un token/zombie possa trasferirlo significa che almeno una di queste condizioni dovrà essere vera:
 
->`zombieToOwner` per` _tokenId` è uguale a `msg.sender`
+>`zombieToOwner` per `_tokenId` è uguale a `msg.sender`
 
 >oppure
 
diff --git a/it/5/09-safemath-1.md b/it/5/09-safemath-1.md
index 8b8608369..e5c4043c2 100644
--- a/it/5/09-safemath-1.md
+++ b/it/5/09-safemath-1.md
@@ -438,7 +438,7 @@ uint8 number = 255;
 number++;
 ```
 
-In questo caso, lo abbiamo fatto andare in overflow — quindi `number` è controintuitivamente ora uguale a `0` anche se lo abbiamo aumentato. (Se aggiungi 1 al binario `11111111`, si reimposta su` 00000000`, come un orologio che va da `23:59` a `00:00`).
+In questo caso, lo abbiamo fatto andare in overflow — quindi `number` è controintuitivamente ora uguale a `0` anche se lo abbiamo aumentato. (Se aggiungi 1 al binario `11111111`, si reimposta su `00000000`, come un orologio che va da `23:59` a `00:00`).
 
 L'underflow è simile, dove se sottrai `1` da un `uint8` che equivale a `0`, ora sarà uguale a `255` (perché `uint`s non è firmato e non può essere negativo).
 
diff --git a/it/5/11-safemath-3.md b/it/5/11-safemath-3.md
index ea2ca2e74..c1ef36359 100644
--- a/it/5/11-safemath-3.md
+++ b/it/5/11-safemath-3.md
@@ -521,7 +521,7 @@ function add(uint256 a, uint256 b) internal pure returns (uint256) {
 // Quindi non andrà in overflow a 2^8, poiché 256 è un `uint256` valido.
 ```
 
-Questo significa che avremo bisogno di implementare altre 2 librerie per prevenire overflow/underflow con i nostri `uint16` e `uint32`. Possiamo richiamare `SafeMath16` e` SafeMath32`.
+Questo significa che avremo bisogno di implementare altre 2 librerie per prevenire overflow/underflow con i nostri `uint16` e `uint32`. Possiamo richiamare `SafeMath16` e `SafeMath32`.
 
 Il codice sarà esattamente lo stesso di SafeMath, tranne per il fatto che tutte le istanze di `uint256` saranno sostituite da `uint32` o `uint16`.
 
@@ -535,6 +535,6 @@ Assegnazione:
 
 1. Dichiara che stiamo usando `SafeMath32` per `uint32`.
 
-2. Dichiara che stiamo usando `SafeMath16` per` uint16`.
+2. Dichiara che stiamo usando `SafeMath16` per `uint16`.
 
 3. C'è un'altra riga di codice in ZombieFactory dove dovremmo usare un metodo di SafeMath. Abbiamo lasciato un commento per indicare dove.
diff --git a/jp/1/datatypes.md b/jp/1/datatypes.md
index 64c589ee2..0abaa35cc 100644
--- a/jp/1/datatypes.md
+++ b/jp/1/datatypes.md
@@ -42,7 +42,7 @@ contract Example {
 
 `uint`というのは、符号なし整数のデータ型で、こいつは **負数ではない**ということを示しているのだ。この他に`int`という符号付整数もあるから覚えておくようにな。
 
-> 注: Solidityでは、 `uint`は256ビットの符号なし整数である`uint256`のエイリアスです。 `uint8`、` uint16`、 `uint32`など、少ないビット数でuintを宣言することもできます。しかし、一般的には、後のレッスンで説明するような特定の場合を除いて、単に` uint`を使います。
+> 注: Solidityでは、 `uint`は256ビットの符号なし整数である`uint256`のエイリアスです。 `uint8`、`uint16`、 `uint32`など、少ないビット数でuintを宣言することもできます。しかし、一般的には、後のレッスンで説明するような特定の場合を除いて、単に` uint`を使います。
 
 # テストの実行
 
diff --git a/no/2/12-multiplereturns.md b/no/2/12-multiplereturns.md
index d52b61810..edba61843 100644
--- a/no/2/12-multiplereturns.md
+++ b/no/2/12-multiplereturns.md
@@ -157,6 +157,6 @@ La oss lage en funksjon som henter kitty-genene fra kontrakten:
 
   > Noter: I vår `KittyInterface`, `genes` er et `uint256` — men hvis du husker leksjon 1, `uint` er et alias for `uint256` — de er en og samme ting.
 
-3. Funksjonen skal da kalle funksjonen `kittyContract.getKitty` med`_kittyId` og lagre `genes` i `kittyDna`. Husk - `getKitty` returnerer massevis av variabler. (10 for å være nøyaktig - jeg er snill, jeg regnet dem for deg!). Men alt vi bryr oss om er den siste, `genes`. Teller kommaene dine forsiktig!
+3. Funksjonen skal da kalle funksjonen `kittyContract.getKitty` med `_kittyId` og lagre `genes` i `kittyDna`. Husk - `getKitty` returnerer massevis av variabler. (10 for å være nøyaktig - jeg er snill, jeg regnet dem for deg!). Men alt vi bryr oss om er den siste, `genes`. Teller kommaene dine forsiktig!
 
 4. Sist men ikke minst, funksjonen skal kalle på `feedAndMultiply`, og gi den `_zombieId` og `kittyDna`.
diff --git a/no/2/3-msgsender.md b/no/2/3-msgsender.md
index 4036e9d55..bb689e38c 100644
--- a/no/2/3-msgsender.md
+++ b/no/2/3-msgsender.md
@@ -105,7 +105,7 @@ function setMyNumber(uint _myNumber) public {
 
 function whatIsMyNumber() public view returns (uint) {
   // Hent verdien som er lagret i avsenderens adresse
-  // Vil være `0` hvis avsenderen ikke har kalt` setMyNumber` ennå
+  // Vil være `0` hvis avsenderen ikke har kalt `setMyNumber` ennå
   return favoriteNumber[msg.sender];
 }
 ```
diff --git a/no/3/05-timeunits.md b/no/3/05-timeunits.md
index ad7cb8051..d80e97af0 100644
--- a/no/3/05-timeunits.md
+++ b/no/3/05-timeunits.md
@@ -197,7 +197,7 @@ Variabelen `now` vil returnere gjeldende unix tidsstempel (antall sekunder som h
 
 > Noter: Unix-tid lagres tradisjonelt i et 32-biters nummer. Dette vil funke til `År 2038` - problemet er, 32-biters unix tidsstempler vil overløpe og ødelegge mange eldre systemer. Så hvis vi ønsker at vår DApp skulle fortsette å løpe 20 år fra nå, kunne vi bruke et 64-biters nummer i stedet - men brukerne våre må bruke mer gas til å bruke vår DApp i mellomtiden. Designbeslutninger!
 
-Solidity inneholder også tidsenhetene `seconds`, `minutes`,`hours`,`days`, `weeks` og`years`. Disse vil konvertere til en `uint` av antall sekunder i den lengden av tiden. Så `1 minutes` er `60`, `1 hours` er`3600` (60 sekunder x 60 minutter), `1 days` er `86400` (24 timer x 60 minutter x 60 sekunder) etc.
+Solidity inneholder også tidsenhetene `seconds`, `minutes`,`hours`,`days`, `weeks` og `years`. Disse vil konvertere til en `uint` av antall sekunder i den lengden av tiden. Så `1 minutes` er `60`, `1 hours` er `3600` (60 sekunder x 60 minutter), `1 days` er `86400` (24 timer x 60 minutter x 60 sekunder) etc.
 
 Her er et eksempel på hvordan disse tidsenhetene kan være nyttige:
 
diff --git a/pt/7/02.md b/pt/7/02.md
index 9486d7053..45d5250b0 100644
--- a/pt/7/02.md
+++ b/pt/7/02.md
@@ -477,7 +477,7 @@ A primeira coisa a observar é que estamos importando de um arquivo chamado `ZBG
 
 > Nota: alguns desses outros arquivos são muito grandes, por isso não os incluiremos na lição. Você pode acessar a fonte completa em <a href="https://github.com/loomnetwork/zb_game_mode" target=_blank>este repositório github</a>. Mas você não precisa se preocupar em ler / entender o conteúdo desses arquivos - explicaremos as partes relevantes que você precisa saber para criar seu modo de jogo personalizado.
 
-Como o nosso contrato, `ExampleGame`, herda de` ZBGameMode`, isso nos dá acesso a um monte de estruturas de dados comuns e métodos auxiliares que criamos para tornar sua vida mais fácil como um desenvolvedor de modo de jogo personalizado.
+Como o nosso contrato, `ExampleGame`, herda de `ZBGameMode`, isso nos dá acesso a um monte de estruturas de dados comuns e métodos auxiliares que criamos para tornar sua vida mais fácil como um desenvolvedor de modo de jogo personalizado.
 
 Nós abstraímos isso em uma biblioteca, então você não precisará colocar a mesma lógica clichê em cada modo de jogo personalizado.
 
diff --git a/pt/7/03.md b/pt/7/03.md
index 54a2e52c0..152c9d72a 100644
--- a/pt/7/03.md
+++ b/pt/7/03.md
@@ -479,13 +479,13 @@ material:
 
 Neste capítulo, vamos desconstruir aquele desagradável array de bytes, `serializedGameState`, em algo que possamos facilmente ler e interagir.
 
-Uma das estruturas auxiliares que temos acesso em `ZBGameMode.sol` é chamada de` GameState` - e é uma estrutura de dados que contém todos os dados dentro de `serializedGameState`.
+Uma das estruturas auxiliares que temos acesso em `ZBGameMode.sol` é chamada de `GameState` - e é uma estrutura de dados que contém todos os dados dentro de `serializedGameState`.
 
 Vamos dar uma olhada no que há dentro.
 
 ## `GameState`
 
-`GameState` é uma` struct` que contém todo o estado da partida atual - e todas as variáveis ​​que podemos querer alterar. Se parece com isso:
+`GameState` é uma `struct` que contém todo o estado da partida atual - e todas as variáveis ​​que podemos querer alterar. Se parece com isso:
 
 > Observação: não se preocupe em entender o que cada parte disso faz ainda - embora a maioria delas seja autoexplicativa. Vamos dividir isso um por um com exemplos do mundo real em capítulos futuros. Isso é apenas para lhe dar uma visão geral de nível superior.
 
@@ -540,7 +540,7 @@ A primeira coisa que você quer fazer é declarar um novo `GameState` em memóri
 GameState memory gameState;
 ```
 
-Então, queremos usar a função `init` para ler todos os dados de` serializedGameState` e usá-lo para preencher nosso `gameState` com dados:
+Então, queremos usar a função `init` para ler todos os dados de `serializedGameState` e usá-lo para preencher nosso `gameState` com dados:
 
 ```
 gameState.init(serializedGameState);
@@ -550,7 +550,7 @@ gameState.init(serializedGameState);
 >
 > A parte importante é que a lógica principal do jogo Zombie Battleground está usando exatamente o mesmo formato de codificação e decodificação do `ZBSerializer`, então as duas partes do jogo são capazes de se comunicar e passar um estado de jogo inteiro para frente e para trás.
 
-Agora os dados são preenchidos em `gameState` e poderemos acessar o estado atual do jogo usando as subpropriedades de` gameState`.
+Agora os dados são preenchidos em `gameState` e poderemos acessar o estado atual do jogo usando as subpropriedades de `gameState`.
 
 Por exemplo, se você quiser ver qual é o nome da primeira carta do baralho do Jogador 1, você pode fazer isso com:
 
@@ -568,5 +568,5 @@ Veremos isso em capítulos futuros, conforme precisamos usá-los.
 
 ## Coloque isto à teste
 
-1. Declare um `GameState` em` memory` chamado `gameState`.
-2. Chame `gameState.init` e passe` serializedGameState`.
+1. Declare um `GameState` em `memory` chamado `gameState`.
+2. Chame `gameState.init` e passe `serializedGameState`.
diff --git a/pt/7/05.md b/pt/7/05.md
index 6170dda67..f24981422 100644
--- a/pt/7/05.md
+++ b/pt/7/05.md
@@ -514,16 +514,16 @@ enum Player {
     Player2
 }
 ```
-Para aqueles que não estão familiarizados, no Solidity, um `enum` é uma maneira de criar um tipo de dados definido pelo usuário que é facilmente conversível de e para um` uint`.
+Para aqueles que não estão familiarizados, no Solidity, um `enum` é uma maneira de criar um tipo de dados definido pelo usuário que é facilmente conversível de e para um `uint`.
 
-`enum`s pode ser convertido em` uint`s da seguinte forma:
+`enum`s pode ser convertido em `uint`s da seguinte forma:
 
 ```
 uint(Player.Player1); // == 0
 uint(Player.Player2); // == 1
 ```
 
-E um `uint` pode ser convertido em um` Player`:
+E um `uint` pode ser convertido em um `Player`:
 
 ```
 Player(0); // == Player.Player1
@@ -557,7 +557,7 @@ Além de `changes.changePlayerDefense ()` acima, há uma série de outros métod
 * `changePlayerMaxCardsInPlay` - o número máximo de zumbis que um jogador pode colocar no campo. O padrão é 6.
 * `changePlayerMaxCardsInHand` - o número máximo de cartas que um jogador pode segurar em sua mão ao mesmo tempo. O padrão é 10
 
-Todas essas funções seguem o mesmo formato de `changePlayerDefense` e ​​aceitam dois argumentos: Um enum` Player` e um `uint8`.
+Todas essas funções seguem o mesmo formato de `changePlayerDefense` e ​​aceitam dois argumentos: Um enum `Player` e um `uint8`.
 
 ## Coloque isto à prova
 Vamos criar algumas regras de jogo personalizadas para o nosso modo ExampleGame ajustando alguns desses valores.
diff --git a/pt/7/06.md b/pt/7/06.md
index bf1463660..400d8211a 100644
--- a/pt/7/06.md
+++ b/pt/7/06.md
@@ -593,4 +593,4 @@ bannedCards["Corrupted Goo"] = true;
 ```
 No próximo capítulo, usaremos esse mapeamento para verificar cada carta e ver se ela foi banida, conforme percorremos o deck de cada jogador.
 
-> Nota: Se o seu modo bane tantos cards que há mais cards banidos do que permitidos, provavelmente seria melhor implementar isso como um mapeamento de `allowedCards`, ao invés de` bannedCards`. A implementação interna depende de você, e este `mapeamento` é apenas um exemplo de como você pode fazer isso.
+> Nota: Se o seu modo bane tantos cards que há mais cards banidos do que permitidos, provavelmente seria melhor implementar isso como um mapeamento de `allowedCards`, ao invés de `bannedCards`. A implementação interna depende de você, e este `mapeamento` é apenas um exemplo de como você pode fazer isso.
diff --git a/pt/7/07.md b/pt/7/07.md
index f10d921bf..3b474bb63 100644
--- a/pt/7/07.md
+++ b/pt/7/07.md
@@ -616,8 +616,8 @@ CardInstance[] memory newCards = new CardInstance[](30);
 
 ## Coloque isto à prova
 
-1. Crie um loop `for` que itera através de cada jogador no` gameState`
+1. Crie um loop `for` que itera através de cada jogador no `gameState`
 
-2. Para cada jogador, crie um array de `CardInstance`s chamado` newCards`. O comprimento desta matriz deve ser `gameState.playerStates [i] .cardsInDeck.length`
+2. Para cada jogador, crie um array de `CardInstance`s chamado `newCards`. O comprimento desta matriz deve ser `gameState.playerStates [i] .cardsInDeck.length`
 
-3. Crie um novo `uint` chamado` cardCount` e defina-o igual a `0`.
+3. Crie um novo `uint` chamado `cardCount` e defina-o igual a `0`.
diff --git a/pt/7/08.md b/pt/7/08.md
index 85c44cc6e..dd8d1a075 100644
--- a/pt/7/08.md
+++ b/pt/7/08.md
@@ -603,9 +603,9 @@ Como você pode ver, usamos um loop `for` aninhado para primeiro iterar pela lis
 
 ## Coloque isto à prova
 
-1. Crie um segundo loop `for` que itera através de todos os` cardsInDeck` para cada jogador, como acima
+1. Crie um segundo loop `for` que itera através de todos os `cardsInDeck` para cada jogador, como acima
 
-2. Crie uma instrução `if` que chama uma função` isLegalCard` e passa `gameState.playerStates [i] .cardsInDeck [j]`. Definiremos essa função no próximo capítulo.
+2. Crie uma instrução `if` que chama uma função `isLegalCard` e passa `gameState.playerStates [i] .cardsInDeck [j]`. Definiremos essa função no próximo capítulo.
 
 3. Dentro da instrução `if`, copie o cartão para nosso novo array definindo` newCards [cardCount] `igual a` gameState.playerStates [i] .cardsInDeck [j] `.
 
diff --git a/pt/7/09.md b/pt/7/09.md
index 222413304..caf288340 100644
--- a/pt/7/09.md
+++ b/pt/7/09.md
@@ -601,6 +601,6 @@ Isso ocorre porque, no futuro, ao fazer um novo modo de jogo, você pode bifurca
 
 ## Coloque isto à prova
 
-1. Defina uma função chamada `isLegalCard`. Esta função receberá um argumento, um `CardInstance` chamado` card`, e retornará um `bool`. A função deve ter as propriedades `internal` e` view`.
+1. Defina uma função chamada `isLegalCard`. Esta função receberá um argumento, um `CardInstance` chamado `card`, e retornará um `bool`. A função deve ter as propriedades `internal` e `view`.
 
-2. No corpo da função, deve retornar verdadeiro se o `card.mouldName` NÃO estiver no mapeamento` bannedCards`. Você pode fazer isso com `return (! BannedCards [card.mouldName]);`.
\ No newline at end of file
+2. No corpo da função, deve retornar verdadeiro se o `card.mouldName` NÃO estiver no mapeamento `bannedCards`. Você pode fazer isso com `return (! BannedCards [card.mouldName]);`.
\ No newline at end of file
diff --git a/pt/7/10.md b/pt/7/10.md
index 69dc46b34..7ae8db876 100644
--- a/pt/7/10.md
+++ b/pt/7/10.md
@@ -603,7 +603,7 @@ Voltando para o nosso `for` loop...
 
 Agora nós percorremos os cartões deste jogador, verificamos cada cartão para ter certeza de que é legal e, se for o caso, o adicionamos ao array de `newCards`.
 
-O próximo passo é dizer à estrutura `changes` que queremos trocar o array de cartas antigas deste jogador com as novas` newCards`.
+O próximo passo é dizer à estrutura `changes` que queremos trocar o array de cartas antigas deste jogador com as novas `newCards`.
 
 Podemos fazer isso chamando uma função chamada `changePlayerCardsInDeck`:
 
@@ -612,8 +612,8 @@ Podemos fazer isso chamando uma função chamada `changePlayerCardsInDeck`:
 changes.changePlayerCardsInDeck (Player.Player1, newCards, cardCount);
 `` `
 
-No contexto do nosso loop `for`, o` uint` `i` representa o número do jogador (` 0` para o Jogador 1, `1` para o Jogador 2). Portanto, para o primeiro argumento, podemos usar `Player (i)` - e nosso `enum` converterá o` uint i` em `Player.Player1` ou` Player.Player2`.
+No contexto do nosso loop `for`, o `uint` `i` representa o número do jogador (`0` para o Jogador 1, `1` para o Jogador 2). Portanto, para o primeiro argumento, podemos usar `Player (i)` - e nosso `enum` converterá o` uint i` em `Player.Player1` ou `Player.Player2`.
 
 ## Coloque isto à prova
 
-1. Apenas após nosso segundo loop `for` (mas ainda dentro do primeiro), chame` changes.changePlayerCardsInDeck` como acima, e troque os cartões de `Player (i)` ’s para o array` newCards` que acabamos de criar.
\ No newline at end of file
+1. Apenas após nosso segundo loop `for` (mas ainda dentro do primeiro), chame` changes.changePlayerCardsInDeck` como acima, e troque os cartões de `Player (i)` ’s para o array `newCards` que acabamos de criar.
\ No newline at end of file
diff --git a/ru/2/7-storage.md b/ru/2/7-storage.md
index a76f8ec4c..9c8c60c3a 100644
--- a/ru/2/7-storage.md
+++ b/ru/2/7-storage.md
@@ -110,7 +110,7 @@ contract SandwichFactory {
 }
 ```
 
-Не волнуйся, если пока не все ясно — на протяжение курса мы подскажем, когда использовать `storage`, а когда ` memory`. Компилятор Solidity тоже выдает предупреждение, когда нужно использовать одно из этих ключевых слов.
+Не волнуйся, если пока не все ясно — на протяжение курса мы подскажем, когда использовать `storage`, а когда `memory`. Компилятор Solidity тоже выдает предупреждение, когда нужно использовать одно из этих ключевых слов.
 
 На данный момент достаточно принять как факт, что есть случаи, требующие ясного обозначения `storage` или `memory`! 
 
@@ -126,7 +126,7 @@ contract SandwichFactory {
 
  > Примечание: из-за того, что наша проверялка довольна примитивна, ожидается, что `msg.sender` идет первым и если поменять порядок, то вылетит ошибка. Но вообще когда кодишь, можно использовать любой порядок — оба правильные.
 
-3. Нам нужно получить ДНК этого зомби. Следующее действие функции - задать локального `Zombie` под названием `myZombie` (который будет указателем в `storage`). Установи эту переменную равной индексу `_zombieId` в нашем массиве` zombies`.
+3. Нам нужно получить ДНК этого зомби. Следующее действие функции - задать локального `Zombie` под названием `myZombie` (который будет указателем в `storage`). Установи эту переменную равной индексу `_zombieId` в нашем массиве `zombies`.
 
 У тебя должно получить 4 строчки кода, включая закрывающую скобку `}`. 
 
diff --git a/ru/3/04-gas.md b/ru/3/04-gas.md
index cacd515bc..10dc772d2 100644
--- a/ru/3/04-gas.md
+++ b/ru/3/04-gas.md
@@ -201,7 +201,7 @@ Ethereum похож на большой, медленный, но крайне 
 
 ## Как упаковать структуру, сэкономив газ
 
-Мы упоминали в первом уроке, что есть разные типы `uint`: `uint8`,` uint16`, `uint32` и так далее. 
+Мы упоминали в первом уроке, что есть разные типы `uint`: `uint8`, `uint16`, `uint32` и так далее. 
 
 Обычно использование этих подтипов нецелесообразно, поскольку Solidity резервирует 256 бит в хранилище независимо от размера `uint`. Например, использование `uint8` вместо `uint` (`uint256`) не экономит газ.
 
diff --git a/sk/2/13-kittygenes.md b/sk/2/13-kittygenes.md
index fa0b48520..072de4bbb 100644
--- a/sk/2/13-kittygenes.md
+++ b/sk/2/13-kittygenes.md
@@ -162,7 +162,7 @@ Poďme implemntovať mačacie gény do našeho zombie DNA kódu.
 
 1. Za prvé uprav definíciu funkcie `feedAndMultiply` tak, aby príjmala tretí argument: `string` s názvom `_species`.
 
-2. Po tom čo vypočítaš DNA nového zombie, pridaj podmienku `if` a porovnaj `keccak256` hashe reťazcov `_species` a`"kitty"`.
+2. Po tom čo vypočítaš DNA nového zombie, pridaj podmienku `if` a porovnaj `keccak256` hashe reťazcov `_species` a `"kitty"`.
 
 3. Vo tele `if` podmienky nahraď posledné dve cifry DNA čislom 99. Jedna z možností ako to dosiahnuť je použiť nasledovný metódu: `newDna = newDna - newDna % 100 + 99;`.
 
diff --git a/th/3/09-zombiemodifiers.md b/th/3/09-zombiemodifiers.md
index 45f8fdb92..0dee6c979 100644
--- a/th/3/09-zombiemodifiers.md
+++ b/th/3/09-zombiemodifiers.md
@@ -209,6 +209,6 @@ function driveCar(uint _userId) public olderThan(16, _userId) {
 
 2. ในฟังก์ชั่นนี้ ก่อนอื่นเราจะต้องทำการยืนยันความถูกต้องว่า `msg.sender` มีค่าเท่ากับ `zombieToOwner[_zombieId]` โดยการใช้ `require` statement
 
-3. ต่อมาฟังก์ชั่นจะต้องตั้งค่า `zombies[_zombieId].name` ให้เท่ากับ`_newName`
+3. ต่อมาฟังก์ชั่นจะต้องตั้งค่า `zombies[_zombieId].name` ให้เท่ากับ `_newName`
 
 3. สร้างอีกฟังก์ชั่นหนึ่งขึ้นมาโดยใช้ชื่อว่า `changeDna` ไว้ด้านล่างฟังก์ชั่น `changeName` เนื้อหาและความหมายต่างๆ เหมือนกับของใน `changeName` เว้นแต่ argument ที่ 2 นั้นจะต้องเปลี่ยนให้เป็น `_newDna` (ชนิด `uint`) แทน และควรมีค่า `20` ในส่วนของพารามิเตอร์ `_level` บน `aboveLevel` นอกจากนี้ตัวจะต้องมีการตั้งค่า`dna` ไปเป็น `_newDna`แทนที่จะเป็นการตั้งชื่อของซอมบี้
diff --git a/th/4/battle-06.md b/th/4/battle-06.md
index 692a44708..081fe5734 100644
--- a/th/4/battle-06.md
+++ b/th/4/battle-06.md
@@ -236,7 +236,7 @@ material:
 
 ## มาทดสอบกัน
 
-1. เพิ่ม modifier `ownerOf` เข้าไปยัง `attack` เพื่อให้แน่ใจว่าผู้ที่เรียกใช้นั้นเป็นเจ้าของ`_zombieId`
+1. เพิ่ม modifier `ownerOf` เข้าไปยัง `attack` เพื่อให้แน่ใจว่าผู้ที่เรียกใช้นั้นเป็นเจ้าของ `_zombieId`
 
 2. สิ่งแรกที่ฟังก์ชั่นของเราควรทำได้ก็คือการมี `storage` ไปยังซอมบี้ทั้งสองฝ่ายเพื่อที่จะสามารถ interact กับพวกมันได้ง่ายขึ้น:
 
diff --git a/th/4/battle-08.md b/th/4/battle-08.md
index 51afa1a37..379beb134 100644
--- a/th/4/battle-08.md
+++ b/th/4/battle-08.md
@@ -257,4 +257,4 @@ material:
 
   c. Increment `lossCount` ของ `enemyZombie` (กลายเป็น Loser!!!!!! 😫 😫 😫)
 
-  d. รันฟังก์ชั่น `feedAndMultiply` ต่อมาทำการเช็ค`zombiefeeding.sol` เพื่อหา syntax ในการเรียกใช้มัน ใน argument ที่ 3 (`_species`) ใส่ข้อมูล string `"zombie"` ลงไป (มันจะยังไม่ทำอะไร ณ ตอนนี้ แต่เราจะสามารถเพิ่มคุณสมบัติเพิ่มเติมในการสร้างซ้อมบี้ตัวใหม่ที่มีซอมบี้ด้วยกันเองเป็นพื้นฐานขึ้นมาได้ในอนาคต (zombie-based zombies) หากเราต้องการ)
+  d. รันฟังก์ชั่น `feedAndMultiply` ต่อมาทำการเช็ค `zombiefeeding.sol` เพื่อหา syntax ในการเรียกใช้มัน ใน argument ที่ 3 (`_species`) ใส่ข้อมูล string `"zombie"` ลงไป (มันจะยังไม่ทำอะไร ณ ตอนนี้ แต่เราจะสามารถเพิ่มคุณสมบัติเพิ่มเติมในการสร้างซ้อมบี้ตัวใหม่ที่มีซอมบี้ด้วยกันเองเป็นพื้นฐานขึ้นมาได้ในอนาคต (zombie-based zombies) หากเราต้องการ)
diff --git a/zh/1/events.md b/zh/1/events.md
index c95ec2cac..8ca67fda2 100644
--- a/zh/1/events.md
+++ b/zh/1/events.md
@@ -105,6 +105,6 @@ YourContract.IntegersAdded(function(error, result) {
 
 1。 定义一个 `事件` 叫做 `NewZombie`。 它有3个参数: `zombieId` (`uint`)， `name` (`string`)， 和 `dna` (`uint`)。
 
-2。 修改 `_createZombie` 函数使得当新僵尸造出来并加入`zombies`数组后，生成事件`NewZombie`。
+2。 修改 `_createZombie` 函数使得当新僵尸造出来并加入 `zombies`数组后，生成事件`NewZombie`。
 
 3。 需要定义僵尸`id`。 `array.push()` 返回数组的长度类型是`uint`  - 因为数组的第一个元素的索引是 0， `array.push() - 1` 将是我们加入的僵尸的索引。 `zombies.push() - 1` 就是 `id`，数据类型是 `uint`。在下一行中你可以把它用到 `NewZombie` 事件中。
diff --git a/zh/1/puttingittogether.md b/zh/1/puttingittogether.md
index cd8407e53..56e7f08ee 100644
--- a/zh/1/puttingittogether.md
+++ b/zh/1/puttingittogether.md
@@ -70,7 +70,7 @@ material:
 
 # 实战演习
 
-1. 创建一个 `public` 函数，命名为` createRandomZombie`. 它将被传入一个变量 `_name` (数据类型是 `string`)。 _(注: 定义公共函数 `public` 和定义一个私有 `private` 函数的做法一样)_。
+1. 创建一个 `public` 函数，命名为 `createRandomZombie`. 它将被传入一个变量 `_name` (数据类型是 `string`)。 _(注: 定义公共函数 `public` 和定义一个私有 `private` 函数的做法一样)_。
 
 2. 函数的第一行应该调用 `_generateRandomDna` 函数，传入 `_name` 参数, 结果保存在一个类型为 `uint` 的变量里，命名为 `randDna`。