Apply suggestions from code review

Co-authored-by: Salomé Do <117105135+sdo-1A@users.noreply.github.com>

docs/components/COMPONENT_REPLACEMENT.md

@@ -182,12 +182,12 @@ For more information on configuration, you can check this [documentation](../con
 
 ### Subcomponent's context (`.context.ts`)
 
-It is used to define the contract to interact with your component, defining the set of dynamic inputs and outputs that a component has.
+The context of the subcomponent is used to define the contract to interact with your component, defining the set of dynamic inputs and outputs that a component has.
 It is structured into three interfaces:
 
-* `*ContextInput` interface (e.g. `DummyPresContextInput`): it contains all the inputs of a component. Fields must have a documentation.
-* `*ContextOutput` interface (e.g. `DummyPresContextOutput`): it contains all the outputs of a component. Fields must have a documentation.
-* interface `DummyPresContext`: it brings together `ContextInput` and `ContextOutput`, extending `Context<DummyPresContextInput, DummyPresContextOutput>` from `@o3r/core`.
+* `*ContextInput` interface (e.g. `DummyPresContextInput`): contains all the inputs of a component. Fields must have a documentation.
+* `*ContextOutput` interface (e.g. `DummyPresContextOutput`): contains all the outputs of a component. Fields must have a documentation.
+* `DummyPresContext` interface: brings together `ContextInput` and `ContextOutput`, extending `Context<DummyPresContextInput, DummyPresContextOutput>` from `@o3r/core`.
 
 ```typescript
 import {Context} from '@o3r/core';
@@ -295,9 +295,9 @@ Instead, we will simply use an ``ng-template`` tag to which we apply the Otter `
 
 ## Known limitations
 
-The main limitation is that it is not possible to apply any modification to the ``host`` component created by a factory.
+The main limitation is that it is not possible to apply any modifications to the ``host`` component created by a factory.
 
-What it means is that:
+This means that the following:
 
 ````html
 <!-- Host binding -->

docs/components/CONTAINER_PRESENTER.md

@@ -73,8 +73,8 @@ passengers/
 ## Guidelines summary
 
 * A component interacting with external entities (store, services, etc.) may be split into a container and a presenter
-* Subcomponents are located in the related block subcomponents folder. If the subcomponent is a block, it will then be set either in the components root folder (if it has a functional meaning), or at the root of the functional folder in a dedicated sub folder.
-* A component shared among different blocks and hosted in the same functional folder, should be placed in a shared folder under the functional one.
+* Subcomponents are located in the subcomponents folder of the related block. If the subcomponent is a block, it will then be set either in the component's root folder (if it has a functional meaning), or at the root of the functional folder in a dedicated subfolder.
+* A component shared among different blocks and hosted in the same functional folder should be placed in a shared folder under the functional one.
 * Avoid creating useless intermediate folder:
     * A component with only a presenter and no container should not have a presenter folder
     * A functional area containing only one block should not have a sub-folder for it

docs/components/INTRODUCTION.md

@@ -20,7 +20,7 @@ Below you can see the basic files generated for a component (more files can be g
 
 
 ## Component class
-Otter component are Angular component with Otter specific information provided through the `@O3rComponent` decorator.
+Otter components are Angular components with Otter-specific information provided through the `@O3rComponent` decorator.
 ```typescript
 @O3rComponent({
   componentType: 'Component'
@@ -35,14 +35,14 @@ Otter component are Angular component with Otter specific information provided t
 })
 export class ComponentNameComponent {}
 ```
-The object passed to the `@O3rComponent` decorator includes the component type, it can be:
-- a `Block`, a component that handle functional area.
-- a `Page`, a component that display an application route.
-- an `ExposedComponent`, a component that needs to be exposed in your CMS.
-- a `Component`, a component that does not need to be exposed in your CMS.
+The object passed to the `@O3rComponent` decorator includes the component type, which can be:
+- `Block`: a component that handles functional area
+- `Page`: a component that displays an application route
+- `ExposedComponent`: a component that needs to be exposed in your CMS
+- `Component`: a component that does not need to be exposed in your CMS
 
 > [!NOTE]
-> By convention, class names mu be written in PascalCase and variable names in camelCase.
+> By convention, class names must be written in PascalCase and variable names in camelCase.
 
 ## Runtime debugging
 
@@ -51,8 +51,8 @@ To enable the communication between your application and the Chrome Extension yo
 
 ## Next steps
 
-To test your component, you can look to the [fixtures documentation](./FIXTURES.md).
+To test your component, you can look at the [fixtures documentation](./FIXTURES.md).
 
 In case you need to handle different UI flavors or to share a flavor with different logics, we recommend to use the [container / presenter](./CONTAINER_PRESENTER.md) patterns.
 
-In case you need to replace component at runtime, you can have a look to the [component replacement](./COMPONENT_REPLACEMENT.md) mechanism.
+In case you need to replace a component at runtime, you can have a look at the [component replacement](./COMPONENT_REPLACEMENT.md) mechanism.

docs/localization/LOCALIZATION.md

@@ -222,13 +222,13 @@ You can directly generate a localized component with the following command:
 ```shell
 ng g component ComponentName --use-localization
 ```
-Or you can localized it later with:
+Or you can localize it later with:
 ```shell
 ng g @o3r/localization:add-localization --path="/path/for/class.component.ts"
 ```
 
 > [!NOTE]
-> Later you can add localization key with the following command:
+> Later you can add a localization key with the following command:
 > ```shell
 > ng g @o3r/localization:add-localization-key --path="/path/for/class.component.ts" --key=myNewLocalizationKey
 > ```
@@ -237,7 +237,7 @@ ng g @o3r/localization:add-localization --path="/path/for/class.component.ts"
 
 ##### Translation (`*.translation.ts`)
 
-It is used to define the localization variables used by component template. my-component.translation.ts file typically defines an interface which extends `Translation` from `@o3r/core` with all possible variable names used by your presenter template. It also exports a constant which satisfies the above contract. The values for each property are localization keys (real keys from localization bundle).
+It is used to define the localization variables used by a component template. The `my-component.translation.ts` file typically defines an interface which extends `Translation` from `@o3r/core` with all possible variable names used by your presenter template. It also exports a constant which satisfies the above contract. The values for each property are localization keys (real keys from localization bundle).
 
 ```typescript
 import {Translation} from  '@o3r/core';
@@ -255,7 +255,7 @@ export  const translations: MyComponentPresTranslation = {
 
 ##### Localization (`*.localization.json`)
 
-It defines an object being key/value pairs. Each value is a json object having `description` and `defaultValue` properties. Eventually you can reference a global key via $ref using relative path to `global-localization.json` which sits in `src` or in different package in dependencies. The purpose of this file is to provide a default localization for component so that library user can start building pages using components without worrying about localization. `*.localization.json` specifies only default values in english.
+It defines an object of key/value pairs. Each value is a JSON object having `description` and `defaultValue` properties. Eventually you can reference a global key via `$ref` using a relative path to `global-localization.json` which sits in `src` or in different package in dependencies. The purpose of this file is to provide a default localization for a component so that library user can start building pages using components without worrying about localization. The `*.localization.json` file specifies default values only in English.
 
 ```typescript
 {

docs/styling/THEME.md

@@ -21,21 +21,21 @@ For more information on the Amadeus palettes you can refer to [Amadeus Color Gui
 
 ## Create your theme
 
-Find below the process to generate your own theme.
+You can find below the process to generate your own theme.
 
 ### Generate your own theme variables
 
 Create a new theme generator in your repository. It shall generate a map of properties that will be used
-directly in the components stylesheets.
+directly in the component's stylesheets.
 The generator shall take a map of overridden properties in order to allow different variations of the theme.
 
 The theme properties can be computed from private variables. Your private variables are not part of your theme and
 should not be used within the components. There is no guarantee they will always be available in your theme.
 If you find the theme properties lacking, please update the generator and do not rely upon `$overridden-properties`.
 
 **Note**: Your theme generator should always extend the basic generator in the otter library:
-`generate-theme-variables`. This generator sole purpose is to make sure all the mandatory theme properties are
-available with a default value each. It is up to the theme to override it with its own variables.
+`generate-theme-variables`. The sole purpose of this generator is to make sure all the mandatory theme properties are
+available with a default value for each. It is up to the theme to override it with its own variables.
 
 ```scss
 // Generate a map of theme variables for your application and override them with the customer's properties