Fix spelling mistakes in the docs (#549)

Signed-off-by: tempate <danieldiaz@eprosima.com>
eProsima · Sep 19, 2023 · 2a55bb9 · 2a55bb9
1 parent d5f5ffd
commit 2a55bb9
Show file tree

Hide file tree

Showing 7 changed files with 18 additions and 18 deletions.
diff --git a/docs/fastdds/discovery/discovery_server.rst b/docs/fastdds/discovery/discovery_server.rst
@@ -40,7 +40,7 @@ In this architecture there are several key concepts to understand:
   |DataWriters| and |DataReaders|.
 
 - Discovery Server DomainParticipants may be *clients* or *servers*.
-  The only difference between them is on how they handle discovery traffic.
+  The only difference between them is how they handle discovery traffic.
   The user traffic, that is, the traffic among the DataWriters and DataReaders they create, is role-independent.
 
 - All *server* and *client* discovery information will be shared with linked *clients*.
@@ -66,7 +66,7 @@ In this architecture there are several key concepts to understand:
 - A |CLIENT| is a participant that connects to one or more *servers* from which it receives only the discovery
   information they require to establish communication with matching endpoints.
 
-- *Clients* require a beforehand knowledge of the *servers* to which they want to link.
+- *Clients* require prior knowledge of the *servers* to which they want to link.
   Basically it is reduced to the *servers* identity (henceforth called |GuidPrefix_t-api|) and a list of locators
   where the *servers* are listening.
   These locators also define the transport protocol (UDP or TCP) the client will use to contact the *server*.
@@ -88,7 +88,7 @@ In this architecture there are several key concepts to understand:
     which it is connected.
     Any DomainParticipant discovered by the *Server* with no endpoints will not be known by the |SUPER_CLIENT|.
 
-- *Servers* do not require any beforehand knowledge of their *clients*, but their |GuidPrefix_t-api| and locator list
+- *Servers* do not require any prior knowledge of their *clients*, but their |GuidPrefix_t-api| and locator list
   (where they are listening) must match the one provided to the *clients*.
   *Clients* send discovery messages to the *servers* at regular intervals (ping period) until they receive message
   reception acknowledgement.

diff --git a/docs/fastdds/discovery/general_disc_settings.rst b/docs/fastdds/discovery/general_disc_settings.rst
@@ -45,7 +45,7 @@ The possible values are:
 +---------------------+---------------------+--------------------------------------------------------------------------+
 | Discovery Mechanism | Possible values     | Description                                                              |
 +=====================+=====================+==========================================================================+
-| Simple              | |SIMPLE|            | Simple discovery protocol as specified in                                |
+| Simple              | |SIMPLE|            | Simple discovery protocol as specified in the                            |
 |                     |                     | `RTPS standard <https://www.omg.org/spec/DDSI-RTPS/2.2/PDF>`_.           |
 +---------------------+---------------------+--------------------------------------------------------------------------+
 | Static              | |STATIC|            | SPDP with manual EDP specified in XML files.                             |
@@ -66,7 +66,7 @@ The possible values are:
 |                     |                     | This type of sever makes the Discovery Server architecture |br|          |
 |                     |                     | resilient to server destruction.                                         |
 +---------------------+---------------------+--------------------------------------------------------------------------+
-| Manual              | |NONE|              | Disables PDP phase, therefore the is no EDP phase. |br|                  |
+| Manual              | |NONE|              | Disables PDP phase, therefore there is no EDP phase. |br|                |
 |                     |                     | All matching must be done manually through the |br|                      |
 |                     |                     | ``addReaderLocator``, ``addReaderProxy``, ``addWriterProxy`` |br|        |
 |                     |                     | RTPS layer methods.                                                      |

diff --git a/docs/fastdds/discovery/simple.rst b/docs/fastdds/discovery/simple.rst
@@ -80,8 +80,8 @@ Simple EDP Attributes
 | Name                        | Description                                                    | Type        | Default |
 +=============================+================================================================+=============+=========+
 | SIMPLE EDP                  | It defines the use of the SIMPLE protocol as a discovery |br|  | ``bool``    | true    |
-|                             | protocol for EDP phase. A DomainParticipant may create |br|    |             |         |
-|                             | DataWriters, DataReaders, both or neither.                     |             |         |
+|                             | protocol for the EDP phase. A DomainParticipant may |br|       |             |         |
+|                             | create DataWriters, DataReaders, both or neither.              |             |         |
 +-----------------------------+----------------------------------------------------------------+-------------+---------+
 | Publication writer and |br| | It is intended for DomainParticipants that implement only |br| | ``bool``    | true    |
 | Subscription reader         | one or more DataWriters, i.e. do not implement DataReaders.    |             |         |
@@ -119,7 +119,7 @@ Initial peers
 According to the `RTPS standard <https://www.omg.org/spec/DDSI-RTPS/2.2/PDF>`_ (Section 9.6.1.1), each
 |RTPSParticipant-api|
 must listen for incoming Participant Discovery Protocol (PDP) discovery metatraffic in two different ports, one linked
-with a multicast address, and another one linked to a unicast address.
+to a multicast address and another one linked to a unicast address.
 *Fast DDS* allows for the configuration of an initial peers list which contains one or more such IP-port address
 pairs corresponding to remote DomainParticipants PDP discovery listening resources, so that the local
 DomainParticipant will not only send its PDP traffic to the default multicast address-port specified by its domain,

diff --git a/docs/fastdds/transport/shared_memory/shared_memory.rst b/docs/fastdds/transport/shared_memory/shared_memory.rst
@@ -40,9 +40,9 @@ This is mainly due to the following reasons:
 Definition of Concepts
 ----------------------
 
-This section describes basic concepts that will help understanding how the Shared Memory Transport works in order
+This section describes basic concepts to help explain how the Shared Memory Transport works in order
 to deliver the data messages to the appropriate :ref:`dds_layer_domainParticipant`.
-The purpose is not to be a exhaustive reference of the implementation, but to be a comprehensive explanation
+The purpose is not to be an exhaustive reference of the implementation, but to be a comprehensive explanation
 of each concept, so that users can configure the transport to their needs.
 
 Many of the descriptions in this section will be made following the example use case depicted in the following figure,
@@ -74,7 +74,7 @@ shared memory mechanisms.
     can lead to communication problems, as processes run by non-privileged users may
     not be able to write into the memory segment.
 
-Every segment has a *segmentId*, a 16 character UUID that uniquely identifies each shared memory segment.
+Every segment has a *segmentId*, a 16-character UUID that uniquely identifies each shared memory segment.
 These *segmentIds* are used to identify and access the segment of each DomainParticipant.
 
 .. _transport_sharedMemory_concepts_buffer:

diff --git a/docs/fastdds/use_cases/large_data/large_data.rst b/docs/fastdds/use_cases/large_data/large_data.rst
@@ -37,12 +37,12 @@ In this scenario, several limitations have to be taken into account:
 
    *eProsima Fast DDS* defines a conservative default message size of 64kB,
    which roughly corresponds to TCP and UDP payload sizes.
-   If the topic data is bigger, it will automatically be be fragmented into several transport packets.
+   If the topic data is bigger, it will automatically be fragmented into several transport packets.
 
 .. warning::
 
    The loss of a fragment means the loss of the entire message.
-   This has most impact on |BEST_EFFORT_RELIABILITY_QOS-api| mode, where the message loss
+   This has the most impact on |BEST_EFFORT_RELIABILITY_QOS-api| mode, where the message loss
    probability increases with the number of fragments
 
 
@@ -167,7 +167,7 @@ The settings for a specific network adapter can be viewed using the one of the f
         ifconfig ${interface}
 
 This will display the configuration of the adapter, and among the parameters the ``txqueuelen``.
-This parameter can be a value between a 1000 and 20000.
+This parameter can be a value between 1000 and 20000.
 
 .. important::
 

diff --git a/docs/fastdds/use_cases/well_known_deployments/well_known_deployments.rst b/docs/fastdds/use_cases/well_known_deployments/well_known_deployments.rst
@@ -36,7 +36,7 @@ This reduces the amount of meta traffic if not all the DomainParticipants
 need to be aware of all the rest of the remote participants present in the network.
 
 Use-case :ref:`use-case-fast-rtps-over-wifi` provides a detailed explanation on how to configure *Fast DDS* for such
-case.
+cases.
 
 .. _wide_deployments_static_edp:
 

diff --git a/docs/fastdds/use_cases/wifi/discovery_server_use_case.rst b/docs/fastdds/use_cases/wifi/discovery_server_use_case.rst
@@ -254,7 +254,7 @@ However, it is possible to connect server isolated networks very much as physica
 can be connected through routers:
 
     * :ref:`discovery_server_partitioning_option1`:
-      Connecting the clients to several servers, so that the clients belong several networks.
+      Connecting the clients to several servers, so that the clients belong to several networks.
     * :ref:`discovery_server_partitioning_option2`:
       Connecting one server to another, so that the networks are linked together.
     * :ref:`discovery_server_partitioning_option3`:
@@ -339,7 +339,7 @@ Option 2
 ^^^^^^^^
 
 Connect one server to the other.
-This means configuring one of the servers to act as client of the other.
+This means configuring one of the servers to act as a client of the other.
 
 Consider two servers, each one managing an isolated network:
 
@@ -350,7 +350,7 @@ Consider two servers, each one managing an isolated network:
     A, 75.63.2D.73.76.72.63.6C.6E.74.2D.31, "192.168.10.60:56543"
     B, 75.63.2D.73.76.72.63.6C.6E.74.2D.32, "192.168.10.57:56542"
 
-In order to communicate both networks we can set server A to act as client of server B:
+In order to communicate both networks we can set server A to act as  a client of server B:
 
 +--------------------------------------------------------+
 | **C++**                                                |