fix: typos and spelling

src/pages/conventions/git.mdx

@@ -19,7 +19,7 @@ afin de maintenir une cohérence dans nos commits.
 | `docs`     | Quand seul la documentation du code change                                     |
 | `perf`     | Changement de code améliorant les performances                                 |
 | `revert`   | Annule un commit précédent                                                     |
-| `style`    | Changement de style (indentation, espaces, etc)                                |
+| `style`    | Changement de style (indentation, espaces, etc.)                                |
 | `test`     | Ajout ou modification de tests                                                 |
 | `refactor` | Changement de code qui n'ajoute pas de fonctionnalité ou de correction de bug  |
 | `ci`       | Changement dans les fichiers et scripts de configuration de CI (Github Action) |
@@ -56,5 +56,6 @@ Ce modèle est composé de 5 branches principales/types :
 
 ### Pourquoi utiliser Git Flow ?
 
-Git Flow offre une meilleur compréhension de chaques parties du projet et de suivre l'avancée d'une partie spécifique. Dans une branche `dev` on fait tous les commits et lorsque le tout fonctionne,
-on merge la branche sur la branche `main` ce qui nuie à la compréhension.
+Git Flow permet, grâce à l'utilisation de deux branches principales, une meilleure organisation de projet.
+La première branche, nommée main, correspond à la version du code stable, utilisable en production.
+La seconde, nommée dev, correspond à la version en cours de développement et est donc la branche de travail.

src/pages/index.mdx

@@ -2,12 +2,12 @@ import { Callout } from 'nextra/components'
 
 # Introduction
 
-Bienvenue sur Archipel Project ! Ce site sert de base de connaissance pour rassembler toutes les informations et ressources nécessaire
+Bienvenue sur Archipel Project ! Ce site sert de base de connaissance pour rassembler toutes les informations et ressources nécessaires
 au développement du projet.
 
 ## Qu'est ce qu'Archipel Project ?
 
-Archipel est un projet visant à implémenter un serveur Minecraft de manière plus optimisée et rapide sous forme de micro services. [En savoir plus](https://archipel-project.github.io/dev-blog) sur le projet Archipel.
+Archipel est un projet visant à implémenter un serveur Minecraft de manière plus optimisée et rapide sous forme de microservices. [En savoir plus](https://archipel-project.github.io/dev-blog) sur le projet Archipel.
 
 ## Où se trouve le projet ?
 
@@ -18,15 +18,15 @@ Le projet est hébergé sur [Github](https://github.com/archipel-project). Il es
 * [Core](https://github.com/archipel-project/core)
 * [Storage](https://github.com/archipel-project/storage)
 * [Tools](https://github.com/archipel-project/tools)
-* [Client](https://github.com/archipel-project/client): client de débug pour le projet
+* [Client](https://github.com/archipel-project/client) : client de débug pour le projet
 * [mc-packet-lib](https://github.com/archipel-project/mc-packet-lib)
 * [Documentation](https://github.com/archipel-project/docs)
 * [Dev blog](https://github.com/archipel-project/dev-blog)
 
 ## Comment contribuer ?
 
 Pour contribuer au projet [Archipel](https://github.com/archipel-project), vous devez faire un [fork](https://docs.github.com/en/get-started/quickstart/fork-a-repo) 
-sur votre compte GitHub du dépôts qui vous intéresse. Une fois les modifications faites, vous devrez faire une Pull Request qui sera analysée.
+sur votre compte GitHub du dépôt qui vous intéresse. Une fois les modifications faites, vous devrez faire une Pull Request qui sera analysée.
 
 ### Éditeurs recommandés
 

src/pages/specs.mdx

@@ -6,7 +6,7 @@ import { GalleryVerticalEnd } from 'lucide-react'
 ## Fonctionnalités à choisir
 
 - [ ]  Compatibilité avec le protocole vanilla
-    - [ ]  Ce layer doit-il être un module ? (du genre traduction la polymer?)
+    - [ ]  Ce layer doit-il être un module ? (du genre traduction la polymer ?)
     - [ ]  Utilisation de raknetify ?
 - [ ]  Pas de limitations techniques sur la high limit
 - [x]  Écrit en Rust

src/pages/specs/blocks.mdx

@@ -1,6 +1,6 @@
-# Blocks
+# Blocs
 
-- un block placé n’est qu'un entier sur 4 bytes (son id) dans un chunk
-- plusieurs variations d'un block sont des blocks différents, il n'y a pas de système de metadata à part les tile entity
-- les fonctions associés aux blocks (tick, update, on break, etc) sont toutes stockées dans un array, l'id du block devra être utilisée comme index pour récupérer ces fonctions
-- il doit être possible de créer des blocks avec une plage d'id contiguë pour tester facilement si un block fait partie d'un groupe (s'il est compris dans la plage d'id), utile pour gérer des variations d'un block (redstone, piston, escalier, blocks waterlogged, etc)
+- un bloc placé n’est qu'un entier sur 4 bytes (son id) dans un chunk
+- plusieurs variations d'un bloc sont des blocs différents, il n'y a pas de système de metadata à part pour les tile entity
+- les fonctions associées aux blocs (tick, update, on break, etc.) sont toutes stockées dans un array, l'id du bloc devra être utilisé comme index pour récupérer ces fonctions
+- il doit être possible de créer des blocs avec une plage d'id contiguë pour tester facilement si un bloc fait partie d'un groupe (s'il est compris dans la plage d'id), ce qui est utile pour gérer les variations d'un bloc (redstone, piston, escalier, blocs waterlogged, etc.)

src/pages/specs/chunks.mdx

@@ -1,19 +1,19 @@
 # Chunks
 
-- Un chunk est une unité de 16×16×16 blocks, soit 4096 blocks au total, il contient:
+- Un chunk est une unité de 16×16×16 blocs, soit 4096 blocs au total, il contient :
     - ses propres coordonnées relatives dans le monde
     - des flags (voir plus bas)
-    - les id des blocks qui le compose
+    - les id des blocs qui le compose
     - un array de 2048 octets pour les données de lumière (soit 4 bits par niveau de lumière)
     - la liste des (id) entités (+tileEntity ?) qui s'y trouvent.
-- Il doit toujours avoir une taille statique en mémoire, cependant n'avoir aucune forme de compression serait une énorme perte d'espace (il y a beaucoup de chunks composés d'à peine une dizaine de blocks, voir que d'un block uniquement), afin de palier à ce problème, 2 implémentations d'un chunks :
-    - une version compressée avec une palette qui traduit les blocks sur 4 bits
-    - la représentation sur 4 bytes (cela permet de diviser par deux là taille d'un chunks en mémoire pour des id globaux d'un block sur 1 octet, par 4 si les blocks sont représentés sur 2 octets).
-- Un chunk dois porter en en-tête les flags suivant :
-    - est-ce un chunk null (un simple trou dans le vecteur de stockage qui peut être refill
+- Il doit toujours avoir une taille statique en mémoire, cependant n'avoir aucune forme de compression serait une énorme perte d'espace (de nombreux chunks ne sont composés que d'une dizaine de blocs, voir d'un unique bloc), afin de palier à ce problème on peut implémenter un chunk de deux façons différentes :
+    - une version compressée avec une palette qui traduit les blocs sur 4 bits
+    - la représentation sur 4 bytes (cela permet de diviser par deux là taille d'un chunks en mémoire pour des id globaux d'un bloc sur 1 octet, par 4 si les blocs sont représentés sur 2 octets).
+- Un chunk dois porter en en-tête les flags suivants :
+    - est-ce un chunk null (un simple trou dans le vecteur de stockage qui peut être refill)
     - est-ce qu'il y a besoin d'appliquer du random-tick speed
-    - est-ce qu'il soit être tické ?
-- Un chunk compressé en mémoire ne doit pas nécessiter de traitement complexe. Les chunks nécessitant une mise à jour régulière peuvent être convertis vers un chunk non compressé
-- Le serveur possède deux vecteurs de chunks chargés en mémoire, pour les versions compressées et non compressées, pour les accès au chunks en fonction de leurs coordonnées, une map liant position à l'index du chunk dans le vecteur devra être utilisé. La vectorisation des chunks garantie que le tick soit rapide et limite les cache miss
+    - est-ce qu'il doit être tické ?
+- Un chunk compressé en mémoire ne doit pas nécessiter de traitement complexe. Les chunks nécessitant une mise à jour régulière peuvent être convertis vers un chunk non compressé.
+- Le serveur possède deux vecteurs de chunks chargés en mémoire, pour les versions compressées et non compressées, pour les accès au chunks en fonction de leurs coordonnées, une map liant la position à l'index du chunk dans le vecteur devra être utilisé. La vectorisation des chunks garantie que le tick soit rapide et limite les cache miss
 - Pourquoi utiliser uniquement deux types de chunks : des variantes de palettes sur 5, 6, 7 et 8 bits augmenterais beaucoup la complexité du programme, avec une légère diminution de la quantité de mémoire utilisée mais aussi une perte en vitesse lors de la mise à jour, car il faudrait négocier avec plus d'objets de différentes tailles
-- Tous les chunks compressé en mémoire doivent avoir la même taille, il en va de même avec les chunks non compressés
+- Tous les chunks compressés en mémoire doivent avoir la même taille, il en va de même avec les chunks non compressés

src/pages/specs/nomenclature.mdx

@@ -2,12 +2,12 @@
 
 ## Plugins
 
-Archive/dossier contenant l’ensemble des ressources nécessaires pour charger un projet
+Archive/dossier contenant l’ensemble des ressources nécessaires pour charger un projet.
 
 ## Modules
 
-Fichier lua ou shared libs qui contiennent la logique du plugin (blocks, items, etc.)
+Fichier lua ou shared libs qui contiennent la logique du plugin (blocs, items, etc.).
 
 ## Assets
 
-Ressources supplémentaires utiles pour le plugin
+Ressources supplémentaires utiles pour le plugin.

src/pages/specs/projects.mdx

@@ -29,7 +29,7 @@ Cet outil permettra d'importer et d'exporter des mondes Minecraft en les convert
 ### Proxy
 
 Le proxy est le point d'entrée pour les joueurs. Ils pourront accéder au serveur de jeu en se connectant dessus.
-Ce proxy gèrera la connexion des joueurs, leur authentification et s'occupera d'accéder au bon worker en fonction du monde demandé.
+Ce proxy gérera la connexion des joueurs, leur authentification et s'occupera d'accéder au bon worker en fonction du monde demandé.
 
 ### Authentification
 
@@ -51,8 +51,8 @@ jeu de base au complet (overworld, nether, end).
 
 ### Manager
 
-Le manager sera là pour chapoter les différents services et garder une cohésion. C'est par le biais de ce dernier qu'il sera possible de gérer l'infrastructure du serveur.
-(joueurs, mondes, nodes, backups, etc.)
+Le manager sera là pour chapeauter les différents services et garder une cohésion. C'est par le biais de ce dernier qu'il sera possible de gérer l'infrastructure du serveur
+(joueurs, mondes, nodes, backups, etc.).
 
 ### Client