Refs #22575: solved failing CI

Signed-off-by: Juanjo Garcia <[email protected]>

docs/rst/getting_started/entities.rst

@@ -46,7 +46,7 @@ for a more detailed explanation of the *DomainParticipant* entity in DDS.
 
 Each *DomainParticipant* can communicate only under a single *Domain*,
 (see :ref:`logical entities <logical_entities>` section), which creates a direct connection between each
-*DomainParticipant* and the *Domain* in which it operates. Additioanlly, from the
+*DomainParticipant* and the *Domain* in which it operates. Additionally, from the
 :ref:`entities diagram <fig_entities_diagram>` it can be seen that *DomainParticipant* entities are contained within
 a *Process*. This is because a system process (referred to as a *Process* entity) executes an application using
 *Fast DDS*, instantiating *DomainParticipants*. The same applies to *DataReaders* and *DataWriters* instantiated by a
@@ -57,7 +57,7 @@ a *Process*. This is because a system process (referred to as a *Process* entity
 
 DataWriter
 ----------
-*DataWriter* is the DDS entity reposible for publishing data.
+*DataWriter* is the DDS entity resposible for publishing data.
 Each *DataWriter* is directly contained within a single *DomainParticipant*.
 In addition, since a *DataWriter* is associated with the *Topic* it publishes under, a direct containment relationship
 can be defined between the *DataWriter* and the *Topic*.
@@ -75,7 +75,7 @@ DataReader
 *DataReader* is the DDS entity holding the subscribe function in the communication.
 As is the case with the *DataWriter*, each *DataReader* is directly contained within a single *DomainParticipant*.
 Furthermore, since a *DataReader* is associated to the *Topic* to which it is subscribed,
-a direct containment relationship an be establisjed between the *DataReader* and the *Topic*.
+a direct containment relationship an be established between the *DataReader* and the *Topic*.
 As a result, any *Topic* will contain all *DataReaders* subscribed to it.
 Therefore, each *DataReader* is directly connected to the *DomainParticipant* it belongs to,
 and with the *Topic* to which it is subscribed.

docs/rst/getting_started/monitor.rst

@@ -54,7 +54,7 @@ that could appear with the Simple Discovery Protocol and multicast.
 In configure this type of Domain monitoring, a string with different
 network addresses is required.
 This string consists of one or several network addresses in the format of ``ip_address:port``, where each address
-represents the IP-port pair where a Discovery Server is listening. Multiple network addreses are separated with
+represents the IP-port pair where a Discovery Server is listening. Multiple network addresses are separated with
 ``;``. It is only necessary to connect successfully to one of the specified addresses, as interconnected Discovery
 Servers create a redundant and robust network. However, connecting to all servers is not required.
 
@@ -68,8 +68,8 @@ one in an external network in address ``8.8.8.8:12345``.
 
 In order to clarify how to set this parameter, please visit the
 `Discovery Server CLI tutorial <https://fast-dds.docs.eprosima.com/en/latest/fastddscli/cli/cli.html#discovery>`_.
-The parameter of the Discovery Server *Init New Monitor* button in this application will be used additionally as the input
-to the CLI command.
+The parameter of the Discovery Server *Init New Monitor* button in this application will be used additionally as the
+input to the CLI command.
 
 .. warning::
     Due to the designed architecture for the communication of the Monitor application and the DDS entities,