Merge pull request #118 from fujitatomoya/enable-codespell

Enable codespell

Author: kydos

.github/workflows/codespell.yml

@@ -0,0 +1,27 @@
+name: Codespell
+
+on:
+  pull_request:
+    branches:
+      - master
+  push:
+    branches-ignore:
+      - master
+  workflow_dispatch:
+
+jobs:
+  spellcheck:
+    runs-on: ubuntu-22.04
+    steps:
+      - uses: actions/checkout@v2
+
+      - name: Set up Python
+        uses: actions/setup-python@v2
+        with:
+          python-version: '3.10'
+
+      - name: Install codespell
+        run: pip install codespell==2.4.1
+
+      - name: Run codespell
+        run: codespell --config codespell.cfg

README.md

@@ -59,6 +59,17 @@ docker build -f docker/Dockerfile --build-arg user=$(id -un) --build-arg uid=$(i
 docker run --rm -v $(pwd):/src -p 1313:1313 zenoh_web
 ```
 
+## Development
+
+### Spell Check
+
+This project uses [codespell](https://github.com/codespell-project/codespell) to automatically check for common spelling errors in documentation.
+The spell check is initiated and verified on every pull request via [GitHub Actions workflow](.github/workflows/codespell.yml).
+
+- [codespell.cfg](codespell.cfg) - Main configuration that defines dictionaries, ignore patterns, and skip directories
+- [codespell_whitelist.txt](codespell_whitelist.txt) - Words to ignore (e.g., technical terms, Zenoh release names like "aithusa", "bahamut")
+- [codespell_dictionary.txt](codespell_dictionary.txt) - Custom corrections for common typos (e.g., `colcn->colcon`, `rosabg->rosbag`)
+
 ## License
 
 This project is licensed under the [Eclipse Public License 2.0](LICENSE)

codespell.cfg

@@ -0,0 +1,13 @@
+[codespell]
+# Enable built-in dictionaries/rules.
+# See more details for https://github.com/codespell-project/codespell/tree/main/codespell_lib/data.
+builtin = clear,rare,informal,code
+
+# Ignore words listed in this file.
+ignore-words = codespell_whitelist.txt
+
+# Add custom dictionary file.
+dictionary = codespell_dictionary.txt,-
+
+# Skip checking files in this directory.
+skip = ./public/*,./resources/*,./static/*

codespell_dictionary.txt

@@ -0,0 +1,12 @@
+crate
+CAs
+decypher
+deque
+lets
+medias
+mut
+stdio
+UInt
+WAN
+ws
+WS

codespell_whitelist.txt

@@ -35,10 +35,10 @@ The upcoming version of **zenoh** comes with a few improvements and some new fea
 
 **Generalised Peer-to-Peer and Client Communication**. In the upcoming version of **zenoh** an application can decide at runtime to behave like a peer or a client. Peers route information between themselves and can also route on behalf of clients -- in other terms peers can behave like routers. Peers-to-peer communication is supported for arbitrary connectivity graphs and supports cliques as a special case. 
 
-**Closure-based Discovery**. Discovery in **zenoh** is supported by the **scouting** protocol, in order to ease the deployment of system that wants to leverage a clique connectivity, for cases in which multicast is not avaiable, or desirable, we support now a clousure-based discovery. In other terms starting from a single peer, we can discover its closure, or in other terms the peers that can be reached directly or indirectly from this starting point.
+**Closure-based Discovery**. Discovery in **zenoh** is supported by the **scouting** protocol, in order to ease the deployment of system that wants to leverage a clique connectivity, for cases in which multicast is not available, or desirable, we support now a clousure-based discovery. In other terms starting from a single peer, we can discover its closure, or in other terms the peers that can be reached directly or indirectly from this starting point.
 
 **Region-Based Routing**
-The new version of **zenoh** supports region-based routing. As depicted in the diagram below, this really means two things, (1) routing information required to build and maintain our routing tables scales with the size of the region, and (2) each region can decide wether to route over an arbitrary connectivity graph of assume a clique. This approach to routing will greatly improve scalability and performance by allowing to use the most appropriate routing technique within a region.
+The new version of **zenoh** supports region-based routing. As depicted in the diagram below, this really means two things, (1) routing information required to build and maintain our routing tables scales with the size of the region, and (2) each region can decide whether to route over an arbitrary connectivity graph of assume a clique. This approach to routing will greatly improve scalability and performance by allowing to use the most appropriate routing technique within a region.
 ![zenoh-routing](../../img/routing.png)
 
 ## Performances

content/blog/2020-06-29-zenoh-tidings.md

@@ -9,7 +9,7 @@ draft: false
 We have been waiting this very moment for several months. Months of patient
 dedication, months of hard and creative work. Months in which each and every
 member of the **zenoh** team  has made his and her best to give our little dragon all
-it needed to succed in the complicated world of Internet Scale Protocols.
+it needed to succeed in the complicated world of Internet Scale Protocols.
 
 Today, at about 11.00 Paris Time **Zenoh Aithusa** Hatched Out!
 
@@ -96,7 +96,7 @@ Another goody coming with Zenoh Aithusa is the [DDS plugin](https://github.com/e
 ## What's Next
 In the weeks to come we will be releasing:
 
-- **Zenoh-pico**. A C-based [client stack for zenoh](https://github.com/eclipse-zenoh/zenoh/wiki/Zenoh--For-Microcontrollers) targeting the most constrained environemnts.
+- **Zenoh-pico**. A C-based [client stack for zenoh](https://github.com/eclipse-zenoh/zenoh/wiki/Zenoh--For-Microcontrollers) targeting the most constrained environments.
 
 - **Language Bindings**. More bindings are coming up including Go-Lang and Java APIs.
 

content/blog/2020-10-08-aithusa.md

@@ -255,5 +255,5 @@ You can also test this with the "teleop" demos provided [here](https://github.co
 [**--JE**](https://github.com/JEnoch)
 
 [^1]: **Why 1 domain per robot ?**  
-In most of the cases, you don't need the robots to communicate with each other. But if you let them use the same `ROS_DOMAIN_ID`, their DDS entities in the robots will anyway exchange discovery information with each other leading to a lot of unecessary traffic that could be problematic over wireless communications (as seen in our previous blog). The simplest way to avoid such traffic is to use distinct domains. Other solutions could be specific network configuration, or specific DDS configuration.
+In most of the cases, you don't need the robots to communicate with each other. But if you let them use the same `ROS_DOMAIN_ID`, their DDS entities in the robots will anyway exchange discovery information with each other leading to a lot of unnecessary traffic that could be problematic over wireless communications (as seen in our previous blog). The simplest way to avoid such traffic is to use distinct domains. Other solutions could be specific network configuration, or specific DDS configuration.
 

content/blog/2021-04-28-ROS2-integration.md

@@ -118,7 +118,7 @@ For this purpose, we recently introduced a new option in the zenoh/DDS bridge:
    - *"float"* is the maximum frequency in Hertz; if publication rate is higher, downsampling will occur when routing.
  
 This option can be used multiple times for different frequency per-topic.  
-For instance, if we want such limtations (topic names are fictitious):  
+For instance, if we want such limitations (topic names are fictitious):  
  - from the racecar, we want to re-publish over zenoh those topics with a maximum frequency for each:
    - `position`: 10Hz
    - `speed`: 10Hz

content/blog/2021-09-28-IAC-experiences-from-the-trenches.md

@@ -223,7 +223,7 @@ The scarce memory and flash resources in microcontrollers stresses out the impor
 
 |                                |   |   | **reel_board (Zephyr)** |   |   | **nucleo-f767zi (Zephyr)** |   |   | **ESP32-D0WDQ6 (Arduino)** |
 |--------------------------------|---|---|:-----------------------:|---|---|:--------------------------:|---|---|:--------------------------:|
-|       **Build-in Flash**       |   |   |           1MiB          |   |   |            2MiB            |   |   |            4MiB            |
+|       **Built-in Flash**       |   |   |           1MiB          |   |   |            2MiB            |   |   |            4MiB            |
 | **Empty Binary (Zephyr-only)** |   |   |       68166 bytes       |   |   |        127344 bytes        |   |   |        385859 bytes        |
 |          **Zenoh Publisher**   |   |   |       164654 bytes      |   |   |        186942 bytes        |   |   |        423161 bytes        |