docs: fix english typos

Signed-off-by: Ethan Perruzza <[email protected]>

Author: EthanPERRUZZA

content/about/opensource.en.md

@@ -17,7 +17,7 @@ In practice, open source is both a **legal framework** for collaborative work, a
 
 ## OSRD and Open Source
 
-Applied to OSRD, Open Source has **multiple avantages** :
+Applied to OSRD, Open Source has **multiple advantages** :
  - the algorithms and know-how developed with the project are free for all
  - development cost and results are shared between actors
  - it makes interoperability between software systems easier by helping make the landscape more homogeneous and standardized

content/about/use-case/_index.en.md

@@ -14,7 +14,7 @@ OSRD is meant to fulfill a range of use-cases related to railway planning:
  - [short term capacity management](#short-term-capacity-management)
 
 
-![produits OSRD](osrd_product.en.png)
+![OSRD product](osrd_product.en.png)
 
 
 ## Timetabling

content/blog/news/2023/opendata-fosdem.en.md

@@ -48,7 +48,7 @@ Learn more about [Inspire data model](https://inspire.ec.europa.eu/file/1723/dow
 - Calculate a new field using the following formula to get the length of each track in kilometers:
 
         "length" = $length / 1000 
-- Select electrified parts of the network using the "other_tages" field: 
+- Select electrified parts of the network using the "other_tags" field:
 
         "other_tags" like '%"electrified"=>"yes"%'
         or "other_tags" like '%"electrified"=>"contact_line"%'

content/docs/explanation/running_time_calculation/allowances.en.md

@@ -10,7 +10,7 @@ weight: 50
 
 </font>
 
-As explained in the [calcul du Max Effort Profile](../pipeline/#calculation-of-the-max-effort-profile), the **basic running time** represents the most stretched run normally achievable, i.e. the fastest possible run of the given equipment on the given route. The train accelerates to the maximum, travels as fast as possible according to the different speed limits and driving capabilities, and brakes to the maximum.
+As explained in the [calculation of the Max Effort Profile](../pipeline/#calculation-of-the-max-effort-profile), the **basic running time** represents the most stretched run normally achievable, i.e. the fastest possible run of the given equipment on the given route. The train accelerates to the maximum, travels as fast as possible according to the different speed limits and driving capabilities, and brakes to the maximum.
 
 This basic run has a major disadvantage: if a train leaves 10 minutes late, it will arrive at best 10 minutes late, because by definition it is impossible for it to run faster than the basic run. Therefore, trains are scheduled with one or more allowances added. The allowances are a relaxation of the train's route, an addition of time to the scheduled timetable, which inevitably results in a lowering of running speeds.
 

content/docs/guides/contribute/contribute-code/commit-conventions.en.md

@@ -27,10 +27,10 @@ Ideally:
 - the title should be self-explanatory: no need to read anything else to understand it
 - the commit title is all lower-case
 - the title is clear to a reader not familiar with the code
-- the body of the commit contains a detailled description of the change
+- the body of the commit contains a detailed description of the change
 
 {{% alert title="" color="info"%}}
-An automated check is performed to enforce as much as possible this formating.
+An automated check is performed to enforce as much as possible this formatting.
 {{% /alert %}}
 
 ### Counter-examples of commit titles
@@ -74,6 +74,6 @@ Now, go in `Files` -> `Preferences` -> `Settings`, search for and activate
 the **Always Sign Off** setting.
 
 Finally, when you'll commit your changes via the VS Code interface, your commits
-will automaticaly be signed-off.
+will automatically be signed-off.
 
 *[Continue towards sharing your changes ‣]({{< ref "share-changes">}})*

content/docs/guides/contribute/contribute-code/frontend-conventions.en.md

@@ -41,7 +41,7 @@ Last but not least, a **common** directory offering :
 
 _In progress_
 
-`projects/{nom du projet}/studies/{nom de l'étude}/scenarios/{nom du scenario}`
+`projects/{project's name}/studies/{study's name}/scenarios/{scenario's name}`
 
 ### Styles & SCSS
 
@@ -150,7 +150,7 @@ In the store, you will see the `editoastApi` key containing the cached data of a
 
 Here for example, the `getProjects` endpoint is called.
 
-RTK stores the endpoint's name, as well as the call's parameters, to form an unique key `nomDuEndpoint({ paramètres })`. (here `getProjects({"ordering":"LastModifiedDesc","pageSize":1000})`).
+RTK stores the endpoint's name, as well as the call's parameters, to form an unique key `nomDuEndpoint({ parameter })`. (here `getProjects({"ordering":"LastModifiedDesc","pageSize":1000})`).
 
 ```js
 {
@@ -164,7 +164,7 @@ RTK stores the endpoint's name, as well as the call's parameters, to form an uni
 }
 ```
 
-In this second example, the same endpoint has been called with the ssame `projectId` parameter, but a different `studyId` parameter.
+In this second example, the same endpoint has been called with the same `projectId` parameter, but a different `studyId` parameter.
 
 ##### Serialization of keys in the cache
 

content/docs/guides/contribute/contribute-code/tests.en.md

@@ -2,7 +2,7 @@
 title: "Tests"
 linkTitle: "Tests"
 weight: 6
-description: "Recommandations for testing purpose"
+description: "Recommendations for testing purpose"
 ---
 
 ## Back-end

content/docs/guides/contribute/install-docker.en.md

@@ -49,7 +49,7 @@ It uses colima for virtualizing linux.
 {{% alert color="info" %}}
 If you're using rancher desktop, please either:
 - uninstall the application
-- select `Manual` in `Preferences` > `Application` > `Environement`
+- select `Manual` in `Preferences` > `Application` > `Environnement`
 {{% /alert %}}
 
 {{% alert color="info" %}}

content/docs/railway-wiki/signalling/spacing/ertms/etcs.en.md

@@ -34,13 +34,13 @@ In order to compute any of these curves, a number of things are needed:
 - `T_traction_cutoff`: the time it take to cut off traction
 - braking model, either lambda or gamma:
     - lambda (braking weight/mass)
-    - gamma (contant deceleration at a given speed)
+    - gamma (constant deceleration at a given speed)
 - correction factors (k\_dry and k\_wet for gamma braking) for braking curves
 
 ### Infrastructure
 
 - corrected gradients (it incorporates curvature)
-- odometry balises location
+- odometry balise locations
 
 ## Processes
 
@@ -53,7 +53,7 @@ In order to compute any of these curves, a number of things are needed:
 ### Speed / distance targets
 
 - `EOA` end of movement authority: the location until which the train is allowed to move
-- `SvL` supervized location: the protected location
+- `SvL` supervised location: the protected location
 
 
 ### Curves
@@ -69,4 +69,4 @@ All the curves below are cut below a given release speed:
 - `FLOI` (also called `SBI`, the intervention curve) the minimum of `SBI1` and `SBI2`
 - `WARNING` (warning curve) computed as a shift of `FLOI` by `Twarning`
 - `PS` (permitted speed curve): shift of `WARNING` by time `Tdriver`
-- `INDICATION` is a shift of `PS` by time `Tindication`
+- `INDICATION` is a shift of `PS` by time `Tindication`

content/docs/reference/design-docs/auth/_index.en.md

@@ -16,7 +16,7 @@ and stakeholders. After some interviews, we believe the overall needs to be as f
   - some users are supposed to only view results of operational studies
   - some users only get access to part of the app
   - not everyone can have access to the admin panel
-  - it could be nice to be able to roll experimental features out incrementaly
+  - it could be nice to be able to roll experimental features out incrementally
 - controlling access to data
   - some infrastructures shall only be changed by automated import jobs
   - users might want to control who can mess with what they're currently working on
@@ -207,10 +207,10 @@ DELETE /authn/group/{group_id}
 ## Authorization
 
 As shown in the overall architecture section, to determine if a subject is
-allowed to conduct an action on a ressource, two checks are performed:
+allowed to conduct an action on a resource, two checks are performed:
 
 1. We check that the **roles** of the subject allows the action.
-2. We check that the subject has the **minimum privileges** on the ressource(s) that are required to perform the action.
+2. We check that the subject has the **minimum privileges** on the resource(s) that are required to perform the action.
 
 ### Roles
 
@@ -249,7 +249,7 @@ Given these builtin roles, application roles may look like:
 Roles are _hierarchical_. This is a necessity to ensure that, for example, if we are to introduce a new action related to scenarios, each subject with the role "exploitation studies" gets that new role automatically.
 We'd otherwise need to edit the appropriate existing roles.
 
-Their hierarchy could ressemble:
+Their hierarchy could resemble:
 
 ```mermaid
 %%{init: {"flowchart": {"defaultRenderer": "elk"}} }%%
@@ -304,7 +304,7 @@ Permission checks are performed as follows:
 enum EffectivePrivLvl {
     Owner,    // all operations allowed, including granting access and deleting the resource
     Writer,   // can change the resource
-    Creator,  // can create new subresources
+    Creator,  // can create new sub resources
     Reader,   // can read the resource
     MinimalMetadata, // is indirectly aware that the resource exists
 }
@@ -486,7 +486,7 @@ Back-end:
   - ensures that role / permission checks were performed. Implement two modules: log on missing check, abort on missing check.
   - injects which checks were performed into response headers so it can be tested
 - introduce the concept of rolling stock collections to enable easier rolling stock permission checking
-- write a migration guide to help OSRD developpers navigate the authorization APIs
+- write a migration guide to help OSRD developers navigate the authorization APIs
 
 Front-end:
 
@@ -563,13 +563,13 @@ We considered two patterns for permission management endpoints:
 We found that:
 
 - having separate set of endpoints per resource types brought extra back-end and front-end complexity
-- the only constraint of unified permission management endpoints is that all resource types need globaly unique IDs
-- the globaly unique ID constraint is less costly than the extra complexity of separate endpoints
+- the only constraint of unified permission management endpoints is that all resource types need globally unique IDs
+- the globally unique ID constraint is less costly than the extra complexity of separate endpoints
 
 ### Dynamically enforce permission checks
 
 Ideally, there would be static checks enforcing permission checks.
-However, we found no completly fool proof way to statically do so.
+However, we found no completely fool proof way to statically do so.
 
 Instead, we decided that all permission checks will be registered
 with a middleware, which will either log or raise an error when a