fix obvious typos and english misstakes

src/frontend/src/pages/Chapters/Camel/ChapterDeployContract/course.md

@@ -6,12 +6,12 @@
 
 A smart contract is code written in Michelson langage (a low-level stack-based turing-complete language).
 It contains entrypoints which describe all possible way to interact with a smart contract.
-It contains prototype of each entrypoint. What kind of parameters are exepected to execute an entrypoint
+It defines the prototype of each entrypoint (it specifies the parameters types of the entrypoint)
 It contains the description of storage.
 
 ### Storage
 
-storage is an allocated memory space associated to smart contract. Storage is a persistent data for a smart contract.
+The storage is an allocated memory space associated to a smart contract. The storage is a persistent data store for a smart contract.
 
 The description of the storage is done by strongly-typing the data structure.
 
@@ -22,14 +22,16 @@ Executing an entrypoint takes some parameters and a state of a storage and retur
 
 ![](/images/contract_in_out.png)
 
-Execution of an entrypoint produces a new state of the storage of the smart contract. If executopn did not throw an exception and did not fail then the new state of storage is applied.
+Execution of an entrypoint produces a new state of the storage of the smart contract. If the entrypoint execution did not throw an exception and did not fail then the new state of storage is applied.
 
-Operations are transactions (smart contract invocation) that will be sent to some other contracts and will trigger an entryppoint of the targeted contract or a tez transfer (no invocation of entrypoint). If execution of an entrypoint produces operations (ordered list of transactions) then they are sent and executed following order of the list of operation.
+Operations are transactions (smart contract invocation) that will be sent to some other contracts and will trigger an entrypoint of the targeted contract or a tez transfer (no invocation of entrypoint). If execution of an entrypoint produces operations (an ordered list of transactions) then they are sent and executed following order of the list of operation.
 
 ## Deploy
 
-A smart contract must be deployed to the blockchain in order to be invoked. When deploying a smart contract ot the blockchain , one must specify the initial state of the storage.
+A smart contract must be deployed on the blockchain in order to be invoked. When deploying a smart contract on the blockchain, one must specify the initial state of the storage.
+
 Deployment of a smart contract in Tezos is called "origination".
+
 Here is the syntax of the tezos command line to deploy a smart contract :
 
 ```
@@ -59,9 +61,9 @@ tezos-client transfer <amount> from <user> to <contract_name> --arg '<entrypoint
 <contract_name> name given to the contract
 <entrypoint_invocation> name of the entrypoint and corresponding parameters. exemple 'Increment(5)'.
 
-⚠️ Notice the --arg parameter specifies an entrypoint call.
+⚠️ Notice that the --arg parameter specifies an entrypoint call.
 
-⚠️ Notice the --dry-run parameter simulate invocation of the entrypoint.
+⚠️ Notice that the --dry-run parameter simulate invocation of the entrypoint.
 
 ## Ligo compiler
 
@@ -115,7 +117,7 @@ ligo dry-run [options] code.mligo mainFunc '<entrypoint(p)>' '<storage_state>'
 
 ### Ligo Expression in command line
 
-Let's see some exemple how to transpile a storage ligo expression into a Michelsonone.
+Let's see some exemple how to transpile a storage ligo expression into a Michelson one.
 
 Let's consider this smart contract which associate coordinates to a planet name.
 

src/frontend/src/pages/Chapters/Camel/ChapterDeployContract/index.ts

@@ -3,9 +3,9 @@
 import course from "!raw-loader!./course.md";
 /* eslint import/no-webpack-loader-syntax: off */
 // @ts-ignore
-import exercise from "!raw-loader!./exercise.ligo";
+import exercise from "!raw-loader!./exercise.cmd";
 /* eslint import/no-webpack-loader-syntax: off */
 // @ts-ignore
-import solution from "!raw-loader!./solution.ligo";
+import solution from "!raw-loader!./solution.cmd";
 
 export const data = { course, exercise, solution, supports: {} };

src/frontend/src/pages/Chapters/Camel/ChapterFA12/course.md

@@ -4,7 +4,7 @@
 
 ## Definition
 
-A Financial Applicationis a non-physical asset whose value is derived from a contractual claim, such as bank deposits, bonds, and stocks. Financial assets are usually more liquid than other tangible assets, such as commodities or real estate, and may be traded on financial markets.
+A Financial Application is a non-physical asset whose value is derived from a contractual claim, such as bank deposits, bonds, and stocks. Financial assets are usually more liquid than other tangible assets, such as commodities or real estate, and may be traded on financial markets.
 
 Financial assets are opposed to non-financial assets, property rights which include both tangible property (sometimes also called real assets) such as land, real estate or commodities and intangible assets such as intellectual property, like copyrights, patents, Trademarks etc.
 
@@ -14,19 +14,19 @@ When talking about _token_ or _crypto-currency_, it is a numerical asset emitted
 
 Fungible means secable
 
-Fungible token is a Financial Applicationwhere account balance represents the value associated to an _address_. This value can be splitted into smaller parts which can be transfered to another account.
+Fungible token is a Financial Application where account balance represents the value associated to an _address_. This value can be splitted into smaller parts which can be transfered to another account.
 
-Non-fungible token (NFT) is a Financial Applicationwhose balance cannot be splitted into smaller part. Crypto-kitties is an exemple of non fungible token (on Ethereum blcockchain). For exemple, a video game avatar (such as avatar on world of warcraft) is a character having some skills/attributes (strength, dexterity, ...) one can want to sell its avatar , but cannot sell strength property of its avatar separately. It makes sense to keep tha whole avatar into a unsecable set of attributes.
+Non-fungible token (NFT) is a Financial Application whose balance cannot be splitted into smaller part. Crypto-kitties is an exemple of non fungible token (on Ethereum blcockchain). For exemple, a video game avatar (such as avatar on world of warcraft) is a character having some skills/attributes (strength, dexterity, ...) one can want to sell its avatar , but cannot sell strength property of its avatar separately. It makes sense to keep tha whole avatar into a unsecable set of attributes.
 
 ### Standard
 
 A standard is a set of rules commonly accepted by the community.
-The rules of Financial Applicationdescribes how to create currencies (and transfer between accounts, etc).
+The rules of Financial Application describes how to create currencies (and transfer between accounts, etc).
 
 Depending on the usage of the currency, many sets of rules have been commonly accepted :
 
-- Financial Application1.2 (FA1.2) are rules for fungible token.
-- Financial Application2.0 (FA20) are rules for non fungible token.
+- Financial Application 1.2 (FA1.2) are rules for fungible token.
+- Financial Application 2.0 (FA20) are rules for non fungible token.
 
 For exemple, the creation of a crypto-currency is equivalent to creating a contract which supports the FA1.2 standard.
 All smart contracts supporting the FA12 standard can interact with account and other contracts by transfering coins of our crypto-currency.

src/frontend/src/pages/Chapters/Camel/ChapterFA12/index.ts

@@ -3,9 +3,9 @@
 import course from "!raw-loader!./course.md";
 /* eslint import/no-webpack-loader-syntax: off */
 // @ts-ignore
-import exercise from "!raw-loader!./exercise.ligo";
+import exercise from "!raw-loader!./exercise.cmd";
 /* eslint import/no-webpack-loader-syntax: off */
 // @ts-ignore
-import solution from "!raw-loader!./solution.ligo";
+import solution from "!raw-loader!./solution.cmd";
 
 export const data = { course, exercise, solution, supports: {} };

src/frontend/src/pages/Chapters/Camel/ChapterInterop/course.md

@@ -27,7 +27,7 @@ will accept these definitions and fail with the ones that does not respect the t
 
 ### Entrypoints and annotations
 
-<!-- prettier-ignore -->As seen in chapter Polymorphism, a contract can be called by another contract. Using the predefined function *Tezos.get\_entrypoint\_opt* allows to a calling contract ot point to a specific entry point of the called contract.
+<!-- prettier-ignore -->As seen in chapter Polymorphism, a contract can be called by another contract. The predefined function *Tezos.get\_entrypoint\_opt* allows to call a specific entry point of the called contract.
 
 Here is an exemple. Let's consider the following "Counter" contract :
 
@@ -72,7 +72,7 @@ These annotations works for _or_'s or _variant_ types in LIGO.
 
 ## Interop with Michelson
 
-<!-- prettier-ignore -->To interop with existing Michelson code or for compatibility with certain development tooling, LIGO has two special interop types: *michelson\_or* and *michelson\_pair*. These types give the flexibility to model the exact Michelson output, including field annotations.
+<!-- prettier-ignore -->To interop with existing Michelson code or for compatibility with some development tooling, LIGO has two special interop types: *michelson\_or* and *michelson\_pair*. These types give the flexibility to model the exact Michelson output, including field annotations.
 
 Take for example the following Michelson type that we want to interop with:
 
@@ -114,9 +114,9 @@ let x: z_or = (M_right (y_1) : z_or)
 
 ## Helper functions
 
-Conversions from Ligo types to Michelsontypes requires a precise knowledge of data structures representation.
+Conversions from Ligo types to Michelson types require a precise knowledge of data structures representation.
 
-So it becomes even more relevant with nested pairs that there are many possible decomposition of a record in pairs of pairs.
+So it becomes even more relevant with nested pairs because there are many possible decompositions of a record in pairs of pairs.
 
 The following record structure
 
@@ -288,4 +288,4 @@ let make_abstract_record (z: string) (y: int) (x: string) (w: bool) (v: int) : t
 
 We want you to modify our "inventory" contract. As you can see the storage is mainly composed of an item inventory where each item is a right combed nested pairs. The contract possess a single entry point AddInventory. This _AddInventory_ function adds each element in the inventory (don't worry about duplicates it has already been taken care of).
 
-<!-- prettier-ignore -->1- Complete the implementation of the *update\_inventory* lambda function. This function takes a list of item as parameter and must transform each item in a combed pair structure and add this transformed structure in the storage inventory. (When naming your temporary variables, use *acc* for the accumulator name and *i* for the current item)
+<!-- prettier-ignore -->1- Complete the implementation of the *update\_inventory* lambda function. This function takes a list of item as parameter and must transform each item in a combed pair structure and add this resulting structure in the storage inventory. (When naming your temporary variables, use *acc* for the accumulator name and *i* for the current item)

src/frontend/src/pages/Chapters/Camel/ChapterLambda/course.md

@@ -16,6 +16,7 @@ One could write a new smart contract (V2) and deploy it but it would imply that
 
 In this chapter we will focus on the third solution.
 
+
 ### Versioning by re-emission
 
 Versioning can be done by writing a new smart contract and emitting transactions from the old contract (V1) to migrate storage information to the new contract (V2). This may require a lot of transactions and thus a lot of fees (resulting in a significant price). This price could be paid by the smart contract that would emit transactions or by each user which would invoke a "migrate" entrypoint of V1 contract to send storage information to the new contract. Transaction emission has been seen in chapter 17 with the _Tezos.transaction_ predefined function.

src/frontend/src/pages/Chapters/Camel/ChapterMultisig/course.md

@@ -9,7 +9,7 @@ In some case one may want to execute an action only if many users approve this a
 
 When invoking a smart contract, an entrypoint is called and usually an action is executed (triggering a storage modification and/or transactions emmission).
 The purpose of a multi-signature pattern is to execute an action when all preconditions has been verified. The action that need to be executed depends on the smart contract logic.
-The mutli-signature implementation can be done in a single contract with the smart contract logic or in a separated contract like a proxy contract (which emits transactions to the contract containg the logic).
+The mutli-signature implementation can be done in a single contract with the smart contract logic or in a separated contract like a proxy contract which emits transactions to the contract containing the logic.
 
 ### Rules
 
@@ -19,7 +19,7 @@ The multi-signature pattern can be described with this set of rules :
 - a user can approve an action (proposed by someone else)
 - a user can cancel his approval on an action.
 - an action is automatically executed when it has been approved by enough users (a threshold of number of approvals must be defined)
-- the smart contract must also handle a list of user allowed to approve an action
+- the smart contract must also handle a list of user in order to specify who is allowed to approve an action
 
 optionnaly
 
@@ -30,10 +30,16 @@ More complex rules can be added these basic ones.
 
 ### Implementation of multisig
 
-Let's consider this implementation of the multi-signature pattern. This implementation takes all previously rules into account.
-The smart contract _MultisigProxy_ accepts a proposed message (parameter typed _string_)), when number of approvals is reached the string is used to generate transaction to an other contract _Counter_.
+Let's consider this implementation of the multi-signature pattern. This implementation takes all previously mentionned rules into account.
+
 This smart contract _MultisigProxy_ intends to play the role of a proxy pattern for _Counter_ contract.
 The _Counter_ contract (the exemple at https://ide.ligolang.org/p/-hNqhvMFDFdsTULXq4K-KQ) has been deployed at address : KT1CFBbdhRCNAzNkX56v361XZToHCAtjSsVS
+The _Counter_ contract handle a simple integer counter which can be incemented or decremented.
+
+Instead of invoking the _Counter_ contract, users propose a modification of the counter to the  _MultisigProxy_ contract which will forward it to the _Counter_ contract (if approved by other users).
+
+A user can invoke the entry point *Send* of the smart contract _MultisigProxy_ to propose or approve a modification of the counter. When the number of approvals is reached, the desired modification is sent to the contract _Counter_ via a transaction. A user can invoke the entry point *Withdraw* of the smart contract _MultisigProxy_ to reject a proposed modification.
+
 
 ```
 // Counter contract types

src/frontend/src/pages/Chapters/Camel/ChapterPreprocessor/course.md

@@ -2,7 +2,7 @@
 
 <dialog character="mechanics"></dialog>
 
-Instead of writing the whole code in a single file, it is possible to split code into different files and include some external code into our file. The preprocessor is responsible to handle code inclusion. While working with multiple files we may encounter a problem of cyclic inclusion. To prevent such situation some pre-processor commands are available.
+Instead of writing the whole code in a single file, it is possible to split code into different files and include some external code into our file. The pre-processor is responsible to handle code inclusion. While working with multiple files we may encounter a problem of cyclic inclusion. To prevent such situation some pre-processor commands are available.
 
 * #if
 * #define
@@ -12,15 +12,15 @@ Instead of writing the whole code in a single file, it is possible to split code
 
 ## Include
 
-Preprocessor command *#include* permits code inclusion. It allows to merge some code into your file. Command *#include* requires a path to a ligo file. 
+Pre-processor command *#include* permits code inclusion. It allows to merge some code into your file. Command *#include* requires a path to a ligo file. 
 
 ```
 #include "tzip-12/fa2_interface.mligo"
 ```
 
 ## Define
 
-Preprocessor command *#define* allows to introduce tags. 
+Pre-processor command *#define* allows to introduce tags. 
 
 ```
 #define FA2_NFT_TOKEN
@@ -31,7 +31,7 @@ Such tags can be used with a conditionnal command.
 
 ## Conditionnal
 
-Preprocessor commands *#if*, *#else* and *#endif* allows to consider / ignore some part of the file depending on tags. Tags are defined with the *#define* command.
+Pre-processor commands *#if*, *#else* and *#endif* allows to consider / ignore some part of the file depending on tags. Tags are defined with the *#define* command.
 
 ```
 #if !FA2_NFT_TOKEN
@@ -63,12 +63,13 @@ let substr_special (s: string) : string =
 
 ## Your mission
 
-Our service is modular. we provide to client only desired module and not the extra modules . They have to pay for it !
-The main module *inventory* can be customized. If we define WITH_EXTRA tag then the code in extra.mligo will be included.
-The module *extra* defines the tag EXTRA and implements a function *doSomethingExtra* 
+We are implementing a smart contract with a modular approach.
 
-We want you to make the code responsive to the tag EXTRA
+As you can see in our exercise, when the WITH_EXTRA tag is defined then the code in extra.mligo file is included.
+The module *extra* defines the tag EXTRA and implements a function *doSomethingExtra*.
+
+We want you to make the code responsive to the tag EXTRA.
 
 
-<!-- prettier-ignore -->1- Modify the function *doSomethingInventory* in the inventory contract *inventory* so as to execute *doSomethingExtra* on given parameter if the EXTRA tag is defined. Otherwise apply *removeFirst* to the given parameter.
+<!-- prettier-ignore -->1- Modify the function *doSomethingInventory* in the inventory contract *inventory* so as to execute *doSomethingExtra* on the given parameter if the EXTRA tag is defined. Otherwise execute *removeFirst* on the given parameter.