Apply Markdown's Bold and Italic best practice.

de/1/functions.md

@@ -55,6 +55,6 @@ You would call this function like so:
 
 In our app, we're going to need to be able to create some zombies. Let's create a function for that.
 
-1. Create a function named `createZombie`. It should take two parameters: **__name_** (a `string`), and **__dna_** (a `uint`).
+1. Create a function named `createZombie`. It should take two parameters: ***_name*** (a `string`), and ***_dna*** (a `uint`).
 
 Leave the body empty for now — we'll fill it in later.

en/1/arrays.md

@@ -39,7 +39,7 @@ material:
  }
 ---
 
-When you want a collection of something, you can use an **_array_**. There are two types of arrays in Solidity: **_fixed_** arrays and **_dynamic_** arrays:
+When you want a collection of something, you can use an ***array***. There are two types of arrays in Solidity: ***fixed*** arrays and ***dynamic*** arrays:
 
 ```
 // Array with a fixed length of 2 elements:
@@ -50,7 +50,7 @@ string[5] stringArray;
 uint[] dynamicArray;
 ```
 
-You can also create an array of **_structs_**. Using the previous chapter's `Person` struct:
+You can also create an array of ***structs***. Using the previous chapter's `Person` struct:
 
 ```
 Person[] people; // dynamic Array, we can keep adding to it
@@ -60,7 +60,7 @@ Remember that state variables are stored permanently in the blockchain? So creat
 
 ## Public Arrays
 
-You can declare an array as `public`, and Solidity will automatically create a **_getter_** method for it. The syntax looks like:
+You can declare an array as `public`, and Solidity will automatically create a ***getter*** method for it. The syntax looks like:
 
 ```
 Person[] public people;
@@ -72,4 +72,4 @@ Other contracts would then be able to read from, but not write to, this array. S
 
 We're going to want to store an army of zombies in our app. And we're going to want to show off all our zombies to other apps, so we'll want it to be public.
 
-1. Create a public array of `Zombie` **_structs_**, and name it `zombies`.
+1. Create a public array of `Zombie` ***structs***, and name it `zombies`.

en/1/datatypes.md

@@ -25,7 +25,7 @@ material:
 
 Great job! Now that we've got a shell for our contract, let's learn about how Solidity deals with variables.
 
-**_State variables_** are permanently stored in contract storage. This means they're written to the Ethereum blockchain. Think of them like writing to a DB.
+***State variables*** are permanently stored in contract storage. This means they're written to the Ethereum blockchain. Think of them like writing to a DB.
 
 ##### Example:
 ```

en/1/events.md

@@ -73,9 +73,9 @@ material:
  }
 ---
 
-Our contract is almost finished! Now let's add an **_event_**.
+Our contract is almost finished! Now let's add an ***event***.
 
-**_Events_** are a way for your contract to communicate that something happened on the blockchain to your app front-end, which can be 'listening' for certain events and take action when they happen.
+***Events*** are a way for your contract to communicate that something happened on the blockchain to your app front-end, which can be 'listening' for certain events and take action when they happen.
 
 Example:
 

en/1/functions3.md

@@ -53,7 +53,7 @@ material:
  }
 ---
 
-In this chapter, we're going to learn about function **_return values_**, and function modifiers.
+In this chapter, we're going to learn about function ***return values***, and function modifiers.
 
 ## Return Values
 
@@ -73,21 +73,21 @@ In Solidity, the function declaration contains the type of the return value (in
 
 The above function doesn't actually change state in Solidity — e.g. it doesn't change any values or write anything.
 
-So in this case we could declare it as a **_view_** function, meaning it's only viewing the data but not modifying it:
+So in this case we could declare it as a ***view*** function, meaning it's only viewing the data but not modifying it:
 
 ```
 function sayHello() public view returns (string memory) {
 ```
 
-Solidity also contains **_pure_** functions, which means you're not even accessing any data in the app. Consider the following:
+Solidity also contains ***pure*** functions, which means you're not even accessing any data in the app. Consider the following:
 
 ```
 function _multiply(uint a, uint b) private pure returns (uint) {
  return a * b;
 }
 ```
 
-This function doesn't even read from the state of the app — its return value depends only on its function parameters. So in this case we would declare the function as **_pure_**.
+This function doesn't even read from the state of the app — its return value depends only on its function parameters. So in this case we would declare the function as ***pure***.
 
 > Note: It may be hard to remember when to mark functions as pure/view. Luckily the Solidity compiler is good about issuing warnings to let you know when you should use one of these modifiers.
 

en/1/lessoncomplete.md

@@ -14,8 +14,8 @@ This is just the beginning. We will be releasing a new CryptoZombies lesson each
 
 ### 1. Sign in to save your progress
 
-**_Sign in_** to save your progress by clicking the "Save Progress" link at the top of the page. We'll let you know as soon as we add a new lesson.
+***Sign in*** to save your progress by clicking the "Save Progress" link at the top of the page. We'll let you know as soon as we add a new lesson.
 
 ### 2. Share your zombie with your friends
 
-**_Share_** your zombie on Twitter, blah blah, etc. (Need to insert images / links)
+***Share*** your zombie on Twitter, blah blah, etc. (Need to insert images / links)

en/1/math.md

@@ -34,7 +34,7 @@ Math in Solidity is pretty straightforward. The following operations are the sam
 * Division: `x / y`
 * Modulus / remainder: `x % y` _(for example, `13 % 5` is `3`, because if you divide 5 into 13, 3 is the remainder)_
 
-Solidity also supports an **_exponential operator_** (i.e. "x to the power of y", x^y):
+Solidity also supports an ***exponential operator*** (i.e. "x to the power of y", x^y):
 
 ```
 uint x = 5 ** 2; // equal to 5^2 = 25

en/1/structs.md

@@ -32,7 +32,7 @@ material:
  }
 ---
 
-Sometimes you need a more complex data type. For this, Solidity provides **_structs_**:
+Sometimes you need a more complex data type. For this, Solidity provides ***structs***:
 
 ```
 struct Person {

en/1/web3js.md

@@ -12,7 +12,7 @@ material:
 
 Our Solidity contract is complete! Now we need to write a JavaScript frontend that interacts with the contract.
 
-Ethereum has a JavaScript library called **_Web3.js_**.
+Ethereum has a JavaScript library called ***Web3.js***.
 
 In a later lesson, we'll go over in depth how to deploy a contract and set up Web3.js. But for now let's just look at some sample code for how Web3.js would interact with our deployed contract.
 

en/10/00-overview.md

@@ -11,16 +11,16 @@ Remember that we promised to teach you how to deploy a smart contract?
 
 It's been a while, but the time has come!
 
-In this lesson, we will be teaching you how to deploy to **_Ethereum_** using **_Truffle_**.
+In this lesson, we will be teaching you how to deploy to ***Ethereum*** using ***Truffle***.
 
-And this is not all. You are going to learn how to deploy your smart contracts to **_Loom_** as well😎.
+And this is not all. You are going to learn how to deploy your smart contracts to ***Loom*** as well😎.
 
-Why deploy to **_Loom_**? After all, **_Ethereum_** is the most secure network.
+Why deploy to ***Loom***? After all, ***Ethereum*** is the most secure network.
 
 Yes, we totally agree with that. But on Ethereum each transaction costs _gas_, so your users will have to pay fees for each and every transaction. Also, they will have to wait at least 10 seconds for each transaction to be confirmed.
 
-In a nutshell, **_on Ethereum, all transactions benefit from the same security guarantees_**. For something like a user-facing DApp or a game, this level of security isn't always a requirement. In fact, it just harms the user experience.
+In a nutshell, ***on Ethereum, all transactions benefit from the same security guarantees***. For something like a user-facing DApp or a game, this level of security isn't always a requirement. In fact, it just harms the user experience.
 
-On **_Loom_**, users have access to much speedier and gas-free transactions. This makes **_Loom_** a much better fit for something like a game or a user-facing DApp.
+On ***Loom***, users have access to much speedier and gas-free transactions. This makes ***Loom*** a much better fit for something like a game or a user-facing DApp.
 
 Enough talking! Let's get started😉

en/10/01.md

@@ -23,20 +23,20 @@ So you've worked your way through our previous lessons. Awesome! This means you'
 
 But an important piece of the puzzle is still missing.
 
-That's right... you still have to learn how to **_deploy a smart contract_**.
+That's right... you still have to learn how to ***deploy a smart contract***.
 
 Now, if you have a background in front-end development, you are probably well accustomed to the multitude of tools like *Webpack, Gulp, or Browserify* that make a developer's life simpler.
 
 But what tools do **Solidity** developers use?
 
 ## Truffle
 
-**_Truffle_** is the most popular blockchain development framework for good reason - it's packed with lots of useful features:
+***Truffle*** is the most popular blockchain development framework for good reason - it's packed with lots of useful features:
 
 - easy smart contract compilation
 - automated ABI generation
 - integrated smart contract testing - there's even support for **Mocha** and **Chai**!
-- support for multiple networks - code can be deployed to Rinkeby, **_Ethereum_** or even to **_Loom_**. We'll walk you through this later😉
+- support for multiple networks - code can be deployed to Rinkeby, ***Ethereum*** or even to ***Loom***. We'll walk you through this later😉
 
 Provided that `npm` and `node` have been installed on your computer, we'll want you to install **Truffle** and make it available globally.
 

en/10/02.md

@@ -48,15 +48,15 @@ Don't worry, learning to use **Truffle** won't eat your brains. This chapter wil
 
 So, running the `truffle init` command inside of the `CryptoZombies` directory, should create several directories and some JavaScript and Solidity files. Let's have a closer look:
 
- - **_contracts_**: this is the place where **Truffle** expects to find all our smart contracts. To keep the code organized, we can even create nested folders such as `contracts/tokens`. Pretty neat😉.
+ - ***contracts***: this is the place where **Truffle** expects to find all our smart contracts. To keep the code organized, we can even create nested folders such as `contracts/tokens`. Pretty neat😉.
 
  >Note: `truffle init` should automatically create a contract called `Migrations.sol` and the corresponding migration file. We'll explain them a bit later.
 
- - **_migrations_**: a migration is a JavaScript file that tells **Truffle** how to deploy a smart contract.
+ - ***migrations***: a migration is a JavaScript file that tells **Truffle** how to deploy a smart contract.
 
- - **_test_**: here we are expected to put the unit tests which will be JavaScript or Solidity files. Remember, once a contract is deployed it can't be changed, making it essential that we test our smart contracts before we deploy them.
+ - ***test***: here we are expected to put the unit tests which will be JavaScript or Solidity files. Remember, once a contract is deployed it can't be changed, making it essential that we test our smart contracts before we deploy them.
 
- - **_truffle.js_** and **_truffle-config.js_**: config files used to store the network settings for deployment. **Truffle** needs two config files because on Windows having both `truffle.js` and `truffle.exe` in the same folder might generate conflicts. Long story short - if you are running Windows, it is advised to delete `truffle.js` and use `truffle-config.js` as the default config file. Check out **Truffle**'s <a href="https://truffleframework.com/docs/truffle/reference/configuration" target=_blank>official documentation</a> to further your understanding.
+ - ***truffle.js*** and ***truffle-config.js***: config files used to store the network settings for deployment. **Truffle** needs two config files because on Windows having both `truffle.js` and `truffle.exe` in the same folder might generate conflicts. Long story short - if you are running Windows, it is advised to delete `truffle.js` and use `truffle-config.js` as the default config file. Check out **Truffle**'s <a href="https://truffleframework.com/docs/truffle/reference/configuration" target=_blank>official documentation</a> to further your understanding.
 
 
 But why should I use this directory structure? I'm not used to it and it looks complicated...
@@ -67,7 +67,7 @@ Second, by adhering to this convention your projects will be easily understood b
 
 ## truffle-hdwallet-provider
 
-In this lesson, we will be using _Infura_ to deploy our code to **_Ethereum_**. This way, we can run the application without needing to set up our own **_Ethereum_** node or wallet.
+In this lesson, we will be using _Infura_ to deploy our code to ***Ethereum***. This way, we can run the application without needing to set up our own ***Ethereum*** node or wallet.
 However, to keep things secure, _Infura_ does not manage the private keys, which means it can't sign transactions on our behalf. Since deploying a smart contract requires **Truffle** to sign transactions, we are going to need a tool called `truffle-hdwallet-provider`. Its only purpose is to handle the transaction signing.
 
 >Note: Maybe you are asking why we chose not to install `truffle-hdwallet-provider` in the previous chapter using something like:

en/10/03.md

@@ -27,7 +27,7 @@ Congratulations! Now that we've put the project structure in place and set up `t
 
 Why do we need to compile, you ask?
 
-The _Ethereum Virtual Machine_ can't directly understand Solidity source code as we write it. Thus, we need to run a compiler that will "translate" our smart contract into machine-readable **_bytecode_**. The virtual machine then executes the bytecode, and completes the actions required by our smart contract.
+The _Ethereum Virtual Machine_ can't directly understand Solidity source code as we write it. Thus, we need to run a compiler that will "translate" our smart contract into machine-readable ***bytecode***. The virtual machine then executes the bytecode, and completes the actions required by our smart contract.
 
 Curious about how does the bytecode look like? Let's take a look:
 
@@ -51,7 +51,7 @@ function add(uint16 a, uint16 b) internal returns (uint16) {
 }
 ```
 
-If we're going to compile this function, the Solidity compiler will throw a **_warning_**:
+If we're going to compile this function, the Solidity compiler will throw a ***warning***:
 
 ```
 safemath.sol:110:11: Warning: Function state mutability can be restricted to pure

en/10/04.md

@@ -18,15 +18,15 @@ material:
  };
 ---
 
-Normally at this point, before deploying to **_Ethereum_**, you would want to test your smart contract locally. You can do this using a tool called <a href="https://truffleframework.com/ganache" target=”_blank”>Ganache</a>, which sets up a local **_Ethereum_** network.
+Normally at this point, before deploying to ***Ethereum***, you would want to test your smart contract locally. You can do this using a tool called <a href="https://truffleframework.com/ganache" target=”_blank”>Ganache</a>, which sets up a local ***Ethereum*** network.
 
 However, while testing is very important, it requires an entire lesson to cover — so we’re just going to stick to deployment in this lesson. If you're so inclined, to learn more about testing, I recommend our very own <a href="http://cryptozombies.io/en/lesson/10" target=”_blank”>Testing Smart Contracts with Truffle</a> lesson.
 
 <!-- TODO: update ^^ link, if needed -->
 
-To deploy to **_Ethereum_** we will have to create something called a **migration**.
+To deploy to ***Ethereum*** we will have to create something called a **migration**.
 
-Migrations are JavaScript files that help **Truffle** deploy the code to **_Ethereum_**. Note that `truffle init` created a special contract called `Migrations.sol` that keeps track of the changes you're making to your code. The way it works is that the history of changes is saved onchain. Thus, there's no way you will ever deploy the same code twice.
+Migrations are JavaScript files that help **Truffle** deploy the code to ***Ethereum***. Note that `truffle init` created a special contract called `Migrations.sol` that keeps track of the changes you're making to your code. The way it works is that the history of changes is saved onchain. Thus, there's no way you will ever deploy the same code twice.
 
 ## Creating a New Migration
 

en/10/05.md

@@ -74,11 +74,11 @@ Awesome! You've successfully compiled the source code and created a migration fi
 
 There is still one more thing to do before we can deploy. We'll have to edit the configuration file to tell **Truffle** the networks we want to deploy to.
 
-Wait a minute, I thought there was only one **_Ethereum_** network. What am I missing here?
+Wait a minute, I thought there was only one ***Ethereum*** network. What am I missing here?
 
 ## Ethereum Test Networks
 
-Several public **_Ethereum_** test networks let you test your contracts for free before you deploy them to the main net (remember once you deploy a contract to the main net it can't be altered). These test networks use a different consensus algorithm to the main net (usually PoA), and Ether is free to encourage thorough testing.
+Several public ***Ethereum*** test networks let you test your contracts for free before you deploy them to the main net (remember once you deploy a contract to the main net it can't be altered). These test networks use a different consensus algorithm to the main net (usually PoA), and Ether is free to encourage thorough testing.
 
 In this lesson, we will be using Rinkeby, a public test network created by The Ethereum Foundation.
 
@@ -133,7 +133,7 @@ Config files are often pushed to GitHub, where anyone can see them, leaving you
 
 ### Set up Truffle for Rinkeby and Ethereum main net
 
-Next, to make sure **Truffle** "knows" the networks we want to deploy to, we will have to create two separate objects- one for Rinkeby and the other one for the **_Ethereum_** main net:
+Next, to make sure **Truffle** "knows" the networks we want to deploy to, we will have to create two separate objects- one for Rinkeby and the other one for the ***Ethereum*** main net:
 
 ```JavaScript
 networks: {

en/10/06.md

@@ -28,7 +28,7 @@ material:
  Saving artifacts...
 ---
 
-Great! That was the difficult part — actually deploying to Rinkeby is going to be straightforward. To do this, **Truffle** relies on something called a **_migration_**.
+Great! That was the difficult part — actually deploying to Rinkeby is going to be straightforward. To do this, **Truffle** relies on something called a ***migration***.
 
 # Migrations