diff --git a/creating_packages/define_abi_compatibility.rst b/creating_packages/define_abi_compatibility.rst
index 476ee53f401..8f27620ddb8 100644
--- a/creating_packages/define_abi_compatibility.rst
+++ b/creating_packages/define_abi_compatibility.rst
@@ -74,7 +74,7 @@ Defining a Custom package_id()
------------------------------
The default ``package_id()`` uses the ``settings`` and ``options`` directly as defined, and assumes the
-`semantic versioning `_ for dependencies is defined in ``requires``.
+`semantic versioning `_ for dependencies is defined in ``requires``.
This ``package_id()`` method can be overridden to control the package ID generation. Within the ``package_id()``, we have access to the
``self.info`` object, which is hashed to compute the binary ID and contains:
@@ -394,7 +394,7 @@ When defining a package ID for model dependencies, it is necessary to take into
Versioning Schema
+++++++++++++++++
-By default Conan assumes `semver `_ compatibility. For example, if a version changes from minor **2.0** to **2.1**, Conan will
+By default Conan assumes `semver `_ compatibility. For example, if a version changes from minor **2.0** to **2.1**, Conan will
assume that the API is compatible (headers not changing), and that it is not necessary to build a new binary for it. This also applies to
patches, whereby changing from **2.1.10** to **2.1.11** doesn't require a re-build.
diff --git a/devtools/running_packages.rst b/devtools/running_packages.rst
index 5de8fb66786..5bb14d20df8 100644
--- a/devtools/running_packages.rst
+++ b/devtools/running_packages.rst
@@ -348,7 +348,7 @@ Even if your application doesn't use directly any of these functions, they are o
so, in practice, it's almost always in actual use.
There are other implementations of the C standard library that present the same challenge, such as
-`newlib `_ or `musl `_, used for embedded development.
+`newlib `_ or `musl `_, used for embedded development.
To illustrate the problem, a simple hello-world application compiled in a modern Ubuntu distribution will give the following error when it
is run in a Centos 6 one:
@@ -382,7 +382,7 @@ C++ standard library
++++++++++++++++++++
Usually, the default C++ standard library is `libstdc++ `_, but
-`libc++ `_ and `stlport `_ are other well-known implementations.
+`libc++ `_ and `stlport `_ are other well-known implementations.
Similarly to the standard C library `glibc`, running the application linked with libstdc++ in the older system may result in an error:
@@ -415,7 +415,7 @@ detailed information.
System API (system calls)
+++++++++++++++++++++++++
-New system calls are often introduced with new releases of `Linux kernel `_. If the application, or 3rd-party
+New system calls are often introduced with new releases of `Linux kernel `_. If the application, or 3rd-party
libraries, want to take advantage of these new features, they sometimes directly refer to such system calls (instead of using wrappers
provided by ``glibc``).
diff --git a/integrations/cross_platform/android.rst b/integrations/cross_platform/android.rst
index d2b6c6e8c8d..eae735878e9 100644
--- a/integrations/cross_platform/android.rst
+++ b/integrations/cross_platform/android.rst
@@ -3,7 +3,7 @@
|android_logo| Android
____________________________
-There are several ways to cross-compile packages for `Android `__ platform via conan.
+There are several ways to cross-compile packages for `Android `__ platform via conan.
Using android_ndk_installer package (build require)
=========================================================
@@ -69,7 +69,7 @@ By adjusting ``arch`` setting, you may cross-compile for ``x86`` and ``x86_64``
Using Docker images
===================
-If you're using `Docker `_ for builds, you may consider using docker images from the
+If you're using `Docker `_ for builds, you may consider using docker images from the
`Conan Docker Tools `_ repository.
Currently, Conan Docker Tools provide the following Android images:
diff --git a/integrations/cross_platform/emscripten.rst b/integrations/cross_platform/emscripten.rst
index 0eab243e205..f49673a7a50 100644
--- a/integrations/cross_platform/emscripten.rst
+++ b/integrations/cross_platform/emscripten.rst
@@ -3,7 +3,7 @@
|emscripten_logo| Emscripten
____________________________
-It should be possible to build packages for `Emscripten `__ (`asm.js `_) via the following conan profile:
+It should be possible to build packages for `Emscripten `__ (`asm.js `_) via the following conan profile:
.. code-block:: text
@@ -19,7 +19,7 @@ It should be possible to build packages for `Emscripten `_ (Web Assembly):
+And the following conan profile is required for the `WASM `_ (Web Assembly):
.. code-block:: text
diff --git a/integrations/deployment/appimage.rst b/integrations/deployment/appimage.rst
index 2710652f95d..e6881de453a 100644
--- a/integrations/deployment/appimage.rst
+++ b/integrations/deployment/appimage.rst
@@ -3,7 +3,7 @@
AppImage
--------
-`AppImage `_ (former ``klik``, ``PortableLinuxApps``) is a format for Linux portable applications. Its major advantages are:
+`AppImage `_ (former ``klik``, ``PortableLinuxApps``) is a format for Linux portable applications. Its major advantages are:
- It does not require root permissions.
- It does not require to install any application (it uses :command:`chmod +x`).
diff --git a/integrations/deployment/flatpak.rst b/integrations/deployment/flatpak.rst
index 12152cd68c4..ed82bf942f7 100644
--- a/integrations/deployment/flatpak.rst
+++ b/integrations/deployment/flatpak.rst
@@ -3,14 +3,14 @@
Flatpak
-------
-`Flatpak `_ (former ``xdg-app``) is a package management system to distribute desktop applications for Linux. It is based on `OSTree `_.
+`Flatpak `_ (former ``xdg-app``) is a package management system to distribute desktop applications for Linux. It is based on `OSTree `_.
Flatpak is `RedHat `_ initiative.
Unlike :ref:`AppImage `, usually applications are distributed via `flathub `_ store, and require a special runtime to install applications on target machines.
The major advantage of ``Flatpak`` is sandboxing: each application runs in its own isolated environment. ``Flatpak`` provides fine-grained control to system resources
(e.g. network, bluetooth, host filesystem, etc.). ``Flatpak`` also offers a set of runtimes for various Linux desktop applications, e.g.
-`Freedesktop `_, `GNOME `_ and `KDE `_.
+`Freedesktop `_, `GNOME `_ and `KDE `_.
The `packaging process `__ is:
diff --git a/integrations/deployment/snap.rst b/integrations/deployment/snap.rst
index 0b29de6f925..8928cc7a555 100644
--- a/integrations/deployment/snap.rst
+++ b/integrations/deployment/snap.rst
@@ -6,7 +6,7 @@ Snap
`Snap `_ is the package management system available for the wide range of Linux distributions.
Unlike :ref:`AppImage `, Snap requires a daemon (``snapd``) installed in the system in order to operate. Under the hood, **Snap** is based on
`SquashFS `_.
-``Snap`` is `Canonical `_ initiative. Usually, applications are distributed via `snapcraft `_ store, but it's not mandatory.
+``Snap`` is `Canonical `_ initiative. Usually, applications are distributed via `snapcraft `_ store, but it's not mandatory.
``Snap`` provides fine-grained control to system resources (e.g. camera, removable media, network, etc.).
The major advantage is `plug-in system `_, which allows to easily integrate ``Snap`` with different languages and build systems (e.g. CMake, autotools, etc.).
diff --git a/integrations/deployment/system_package_manager.rst b/integrations/deployment/system_package_manager.rst
index 3ecdff85e4d..00d53bfa142 100644
--- a/integrations/deployment/system_package_manager.rst
+++ b/integrations/deployment/system_package_manager.rst
@@ -10,7 +10,7 @@ method is very convenient for deployment and distribution as it is natively inte
distributions in order to create different packages for them.
- If you want to target different distros, then you need to create one package per supported distro (likely one for
- `Ubuntu `_, one for `Arch Linux `_, etc.), and formats or guidelines for each distro might differ significantly
+ `Ubuntu `_, one for `Arch Linux `_, etc.), and formats or guidelines for each distro might differ significantly
Check out the sections :ref:`makeself `, :ref:`AppImage `,
:ref:`Flatpak ` and :ref:`Snap ` for information on how to create distribution-agnostic packages.
diff --git a/reference/build_helpers/visual_studio.rst b/reference/build_helpers/visual_studio.rst
index 0ee0f068d56..7a0a4c025b1 100644
--- a/reference/build_helpers/visual_studio.rst
+++ b/reference/build_helpers/visual_studio.rst
@@ -128,7 +128,7 @@ Parameters:
- **output_binary_log** (Optional, Defaulted to ``None``): Sets ``/bl`` flag. If set to ``True`` then MSBuild will output a binary log
file called *msbuild.binlog* in the working directory. It can also be used to set the name of log file like this
``output_binary_log="my_log.binlog"``. This parameter is only supported
- `starting from MSBuild version 15.3 and onwards `_.
+ `starting from MSBuild version 15.3 and onwards `_.
- **property_file_name** (Optional, Defaulted to ``None``): Sets ``p:ForceImportBeforeCppTargets``. When ``None`` it will generate a
file named *conan_build.props*. You can specify a different name for the generated properties file.
- **verbosity** (Optional, Defaulted to ``None``): Sets the ``/verbosity`` flag to the specified verbosity level. Possible values are
diff --git a/systems_cross_building/windows_subsystems.rst b/systems_cross_building/windows_subsystems.rst
index f681f5a5dac..0562bffbd55 100644
--- a/systems_cross_building/windows_subsystems.rst
+++ b/systems_cross_building/windows_subsystems.rst
@@ -64,7 +64,7 @@ Controlling the build environment
Building software in a Windows subsystem for a different compiler than MinGW can sometimes be painful.
The reason is how the subsystem finds your compiler/tools in your system.
-For example, the `icu `_ library requires Visual Studio to be built in Windows, but also a subsystem
+For example, the `icu `_ library requires Visual Studio to be built in Windows, but also a subsystem
able to build the Makefile. A very common problem and example of the pain is the ``link.exe`` program.
In the Visual Studio suite, ``link.exe`` is the linker, but in the ``MSYS2`` environment the ``link.exe``
is a tool to manage symbolic links.
diff --git a/videos.rst b/videos.rst
index 19b5aeb5c91..33bb33fc423 100644
--- a/videos.rst
+++ b/videos.rst
@@ -102,7 +102,7 @@ Videos and links
-- "Conan.io C++ Package Manager demo with SFML" by `Charl Botha `_
+- "Conan.io C++ Package Manager demo with SFML" by `Charl Botha `_
.. raw:: html