Enable codespell

.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_whitelist.txt

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

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

@@ -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-10-08-aithusa.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/2021-04-28-ROS2-integration.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-09-28-IAC-experiences-from-the-trenches.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-10-04-zenoh-pico-guide.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        |
 

content/blog/2022-06-09-zenoh-pico-above-and-beyond.md

@@ -30,7 +30,7 @@ Protocols used today to build these systems, such as MQTT, DDS, CoAP and even HT
 
 # Zenoh API for constrained devices
 
-APIs should provide a minimal set of well defined and composable primitives. That's easily said but takes a deep understanding of the problem space and the patience necessary to refine the solution. In Zenoh, we went through a careful thought process in order to understand the abstractions and primitives that must or must not be provided to the users, hiding irrelevant details while not reducing its expressiveness. As a result, Zenoh-Pico provides exactly the same set of primitives as provided by the Zenoh Rust-implementation and its binding, making in fact 99% of Zenoh-C source-code copyable into Zenoh-Pico code.
+APIs should provide a minimal set of well defined and composable primitives. That's easily said but takes a deep understanding of the problem space and the patience necessary to refine the solution. In Zenoh, we went through a careful thought process in order to understand the abstractions and primitives that must or must not be provided to the users, hiding irrelevant details while not reducing its expressiveness. As a result, Zenoh-Pico provides exactly the same set of primitives as provided by the Zenoh Rust-implementation and its binding, making in fact 99% of Zenoh-C source-code copiable into Zenoh-Pico code.
 
 > “(Software design is) a craft...and it has a lot to do with valuing simplicity over complexity. Many people do have a tendency to make things more complicated than they need to be.”
 
@@ -277,7 +277,7 @@ Except for the session opening and closing, Zenoh offers the lowest overhead in
 
 Still, the most important operation is publishing data, and **Zenoh overhead in the wire is 98%, 75% and 64% smaller when compared to OPC-UA, XRCE-DDS and MQTT**. In doing so, Zenoh is considerably less expensive if we consider long-lived sessions that periodically publish information (e.g., IoT sensoring systems making use of Low Throughput Networks). 
 
-As for the keep-alives, in Zenoh they are not sent if any message is transmitted between the session peers in the corresponding lease window, making its overhead non-existent for periodic publishers.
+As for the keep-alive, in Zenoh they are not sent if any message is transmitted between the session peers in the corresponding lease window, making its overhead non-existent for periodic publishers.
 
 ## Flash Memory Overhead
 Flash memory might be an extremely restrictive element in constrained devices like IoT devices, not comprising more than 1MB of flash memory. This means that all the compiled software (including the user code and libraries), firmware and any other data the device can download needs to fit in such a small amount of space.

content/blog/2023-01-17-zenoh-wireshark.md

@@ -28,7 +28,7 @@ Fear not, as now you have a **Zenoh protocol dissector that you can use with Wir
 # How to Install the Zenoh Protocol Dissector?
 Zenoh’s dissector is written in Lua to make it easy to install on any of the Wireshark supported platforms –  Wireshark has a built-in Lua interpreter. As such,  the installation process is as simple as copying the `zenoh.lua` file to the [Wireshark plugin folder](https://www.wireshark.org/docs/wsug_html_chunked/ChPluginFolders.html).
 
-We recommend cloning the [Zenoh protocol dissector Github repository](https://github.com/ZettaScaleLabs/zenoh-dissector) and creating a symbolic link of `zenoh.lua` file to the Wireshark plugin folder. In this way, everytime you fetch the latest changes from the Github repository, it will immediately update the file already being loaded by Wireshark.
+We recommend cloning the [Zenoh protocol dissector Github repository](https://github.com/ZettaScaleLabs/zenoh-dissector) and creating a symbolic link of `zenoh.lua` file to the Wireshark plugin folder. In this way, every time you fetch the latest changes from the Github repository, it will immediately update the file already being loaded by Wireshark.
 
 ```bash
 git clone https://github.com/ZettaScaleLabs/zenoh-dissector <WORKING_DIR>/zenoh-dissector

content/blog/2023-03-21-zenoh-vs-mqtt-kafka-dds.md

@@ -20,7 +20,7 @@ Zenoh community as this evaluation answers a couple of questions we are asked qu
 High performance has always been one of the main goals of Zenoh. While  Zenoh\'s performance is provided for each release (see
 [here](https://zenoh.io/blog/2022-09-30-zenoh-bahamut/#improved-performance),
 [here](https://zenoh.io/blog/2022-04-14-rust-async-eval/), and
-[here](https://zenoh.io/blog/2021-07-13-zenoh-performance-async/)), so far there were no peformance evaluations that
+[here](https://zenoh.io/blog/2021-07-13-zenoh-performance-async/)), so far there were no performance evaluations that
 compared Zenoh with other technologies. Yet, this was a question commonly asked on Zenoh's discord server and on github.
 In this blog, we'll present an evaluation conducted by the [National Taiwan
 University](https://www.ntu.edu.tw/english/) where Zenoh\'s

content/blog/2023-06-05-charmander2.md

@@ -88,7 +88,7 @@ let mut formatter = temperatures::formatter();
 let ke = zenoh::keformat!(formatter, factory = 5, sensor = 42).unwrap();
 ```
 
-- Or use it to parse incoming KEs to extract the informations you actually care about:
+- Or use it to parse incoming KEs to extract the information you actually care about:
 
 ```rust
 let parsed = temperatures::parse(ke).unwrap();

content/blog/2023-07-17-s3-backend.md

@@ -32,7 +32,7 @@ You may ask yourself “what is a backend?”. Well, in Zenoh a backend is a sto
 
 At the moment we had three backend systems:
 
-- [InfluxDB](https://www.influxdata.com/): a time series data platform userful for developers to build IoT, analytics and cloud applications
+- [InfluxDB](https://www.influxdata.com/): a time series data platform useful for developers to build IoT, analytics and cloud applications
   - Repository: [https://github.com/eclipse-zenoh/zenoh-backend-influxdb](https://github.com/eclipse-zenoh/zenoh-backend-influxdb)
 - [RocksDB](http://rocksdb.org/): a high-performance persistent key-value store for fast storage environments
   - Repository: [https://github.com/eclipse-zenoh/zenoh-backend-rocksdb](https://github.com/eclipse-zenoh/zenoh-backend-rocksdb)

content/blog/2023-10-03-zenoh-dragonite.md

@@ -50,7 +50,7 @@ The new [zenoh-dissector](https://github.com/ZettaScaleLabs/zenoh-dissector) mak
     alt="Zenoh Kotlin"
     width="30%" >}}
 
-This release introduces Zenoh to the world of Kotlin, and viceversa ;-). The [Zenoh Kotlin API](https://github.com/eclipse-zenoh/zenoh-kotlin) targets the JVM environment and essentially opens the use of Zenoh to all the JVM-based programming languages.
+This release introduces Zenoh to the world of Kotlin, and vice-versa ;-). The [Zenoh Kotlin API](https://github.com/eclipse-zenoh/zenoh-kotlin) targets the JVM environment and essentially opens the use of Zenoh to all the JVM-based programming languages.
 In this alpha version, you’ll find most of Zenoh’s features. You'll be able to publish, subscribe and query data.
 Next we will be working on platform independent packaging and Android support.
 

content/blog/2024-10-21-zenoh-firesong.md

@@ -100,7 +100,7 @@ let string = String::from_utf8_lossy(sample.value.contiguous());
 Zenoh 1.0.0:
 ```rust
 // Publisher
-// “My Value” is a string that can be diretly converted in bytes, no encoding is automatically set
+// “My Value” is a string that can be directly converted in bytes, no encoding is automatically set
 session.put(“test/foo”, “My Value”).attachment(“My attachment”).await.unwrap(); 
 
 // Subscriber
@@ -634,7 +634,7 @@ Zenoh 1.0.0 adds comprehensive shared memory support with a rich yet unstable AP
 The SHM subsystem is heavily reworked both on the API and implementation side. 
 Shared memory API is currently available in Rust, C and C++ API.
 
-Some key featuers that have been introduced are:
+Some key features that have been introduced are:
 - Decentralised architecture: this provides process isolation to meet safety requirements.
 - No topological constraints: now SHM can be used in any topology (included multi-hop routing networks) as long as data reside in the same shared memory domain;
 - SHM routing with seamless SHM to non-SHM conversion: in case data need to leave the SHM domain, Zenoh will automatically convert it to non-SHM;
@@ -871,7 +871,7 @@ The rationale is to avoid comparing information that, in fact, cannot be compare
 
 ## TLS/mTLS/QUIC Configuration
 
-In Zenoh 1.0.0 we have changed the configuration parameters for TLS/mTLS/QUIC to faciliate the configuration.
+In Zenoh 1.0.0 we have changed the configuration parameters for TLS/mTLS/QUIC to facilitate the configuration.
 
 The following configuration illustrates the changes:
 
@@ -892,7 +892,7 @@ The following configuration illustrates the changes:
   }
 ```
 
-For users already using a TLS configuration, it is sufficient to change the configuration parametes accoring to the following table:
+For users already using a TLS configuration, it is sufficient to change the configuration parameters according to the following table:
 
 |  Old | New  | 
 |---|---|
@@ -907,7 +907,7 @@ For users already using a TLS configuration, it is sufficient to change the conf
 
 ## Zenoh-Pico
 
-Zenoh-Pico implementes now the new [C API](#c-api) as well the new [interest protocol](#interest-protocol) when operating in client mode.
+Zenoh-Pico implements now the new [C API](#c-api) as well the new [interest protocol](#interest-protocol) when operating in client mode.
 Therefore, Zenoh-Pico publishers will now start sending messages on the network only once at least one subscriber is detected, saving energy and bandwidth in case of nodody is interested in the actual data.
 The interest feature will be implemented also for peer mode in the future.
 

content/blog/2024-12-12-zenoh-firesong-1.1.0.md

@@ -116,7 +116,7 @@ int main(int argc, char **argv) {
 }
 ```
 
-### Rasberry Pi Pico
+### Raspberry Pi Pico
 
 We are excited to announce support for the Raspberry Pi Pico series in Zenoh-Pico! This addition makes it possible to leverage Zenoh-Pico’s lightweight and efficient communication capabilities on `RP2040/RP2350`-based devices.
 To get started, check out the new Raspberry Pi Pico section in the [README](https://github.com/eclipse-zenoh/zenoh-pico?tab=readme-ov-file#226-raspberry-pi-pico). This includes detailed instructions for building and running Zenoh-Pico on Pico devices, enabling seamless integration into your IoT projects.

content/blog/2025-04-14-zenoh-gozuryu.md

@@ -248,7 +248,7 @@ A full example as well as working with the channel can be found [there](https://
 
 ### Matching listeners
 
-Zenoh-Pico now supports matching listeners, allowing publishers and queriers to detect when there are active subscribers or queriable matching their key expression. This feature provides applications with greater awareness of their communication state, optimizing resource usage and enabling more responsive behavior. The same functionality is also available in Zenoh-Cpp, ensuring consistency across implementations.
+Zenoh-Pico now supports matching listeners, allowing publishers and queriers to detect when there are active subscribers or queryable matching their key expression. This feature provides applications with greater awareness of their communication state, optimizing resource usage and enabling more responsive behavior. The same functionality is also available in Zenoh-Cpp, ensuring consistency across implementations.
 
 A matching listener can be declared using `z_publisher_declare_background_matching_listener`, which registers a callback that is triggered when the first subscriber connects or when the last subscriber disconnects: