Backport hacktoberfest 2 (#79067)

* Docs: Replace Latin terms in the dev_guide #78997 (#79005)

(cherry picked from commit fbd98cd8246e8554269b2c766db2b2228cc30bd9)

* replace with boolean true/false (#78950)

(cherry picked from commit 78c9fb415954ca630f028fe7a7d154658fc41422)

* docs: replace latin terms with english in the os_guide directory (#79007)

Fixes #79003

(cherry picked from commit 55925958ea8ea48273c7ade660ceea0e9e24f348)

Co-authored-by: Mazen Ramadan <mazenramadan00@gmail.com>
Co-authored-by: Niranjan Meghwal <56632168+NiranjanMeghwal@users.noreply.github.com>
Co-authored-by: Samuel Gaist <samuel.gaist@idiap.ch>

21 files changed, 46 insertions, 46 deletions

diff --git a/docs/docsite/rst/dev_guide/debugging.rst b/docs/docsite/rst/dev_guide/debugging.rst
index 43f9e23dc7..0ed23c5881 100644
--- a/docs/docsite/rst/dev_guide/debugging.rst
+++ b/docs/docsite/rst/dev_guide/debugging.rst
@@ -94,7 +94,7 @@ The following steps use ``localhost`` as the target host, but you can use the sa
       $ python AnsiballZ_ping.py execute
       {"invocation": {"module_args": {"data": "debugging_session"}}, "changed": false, "ping": "debugging_session"}
 
-    This subcommand inserts the absolute path to ``debug_dir`` as the first item in ``sys.path`` and invokes the script using the arguments in the ``args`` file. You can continue to run the module like this until you understand the problem. Then you can copy the changes back into your real module file and test that the real module works via ``ansible`` or ``ansible-playbook``.
+    This subcommand inserts the absolute path to ``debug_dir`` as the first item in ``sys.path`` and invokes the script using the arguments in the ``args`` file. You can continue to run the module like this until you understand the problem. Then you can copy the changes back into your real module file and test that the real module works by using the ``ansible`` or ``ansible-playbook``.
 
 
 .. _simple_debugging:
diff --git a/docs/docsite/rst/dev_guide/developing_api.rst b/docs/docsite/rst/dev_guide/developing_api.rst
index 47fd53779b..3ea552a213 100644
--- a/docs/docsite/rst/dev_guide/developing_api.rst
+++ b/docs/docsite/rst/dev_guide/developing_api.rst
@@ -28,7 +28,7 @@ This example is a simple demonstration that shows how to minimally run a couple
 .. literalinclude:: ../../../../examples/scripts/uptime.py
    :language: python
 
-.. note:: Ansible emits warnings and errors via the display object, which prints directly to stdout, stderr and the Ansible log.
+.. note:: Ansible emits warnings and errors through the display object, which prints directly to stdout, stderr and the Ansible log.
 
 The source code for the ``ansible``
 command line tools (``lib/ansible/cli/``) is `available on GitHub <https://github.com/ansible/ansible/tree/devel/lib/ansible/cli>`_.
diff --git a/docs/docsite/rst/dev_guide/developing_collections_structure.rst b/docs/docsite/rst/dev_guide/developing_collections_structure.rst
index 4ec666ce3a..997b0ad014 100644
--- a/docs/docsite/rst/dev_guide/developing_collections_structure.rst
+++ b/docs/docsite/rst/dev_guide/developing_collections_structure.rst
@@ -199,11 +199,11 @@ To run the plays, users can now use such commands as ``ansible-playbook --e 'tar
 tests directory
 ----------------
 
-Ansible Collections are tested much like Ansible itself, by using the `ansible-test` utility which is released as part of Ansible, version 2.9.0 and newer. Because Ansible Collections are tested using the same tooling as Ansible itself, via `ansible-test`, all Ansible developer documentation for testing is applicable for authoring Collections Tests with one key concept to keep in mind.
+Ansible Collections are tested much like Ansible itself, by using the `ansible-test` utility which is released as part of Ansible, version 2.9.0 and newer. Because Ansible Collections are tested using the same tooling as Ansible itself, by using the `ansible-test`, all Ansible developer documentation for testing is applicable for authoring Collections Tests with one key concept to keep in mind.
 
 See :ref:`testing_collections` for specific information on how to test collections with ``ansible-test``.
 
-When reading the :ref:`developing_testing` documentation, there will be content that applies to running Ansible from source code via a git clone, which is typical of an Ansible developer. However, it's not always typical for an Ansible Collection author to be running Ansible from source but instead from a stable release, and to create Collections it is not necessary to run Ansible from source. Therefore, when references of dealing with `ansible-test` binary paths, command completion, or environment variables are presented throughout the :ref:`developing_testing` documentation; keep in mind that it is not needed for Ansible Collection Testing because the act of installing the stable release of Ansible containing `ansible-test` is expected to setup those things for you.
+When reading the :ref:`developing_testing` documentation, there will be content that applies to running Ansible from source code through a git clone, which is typical of an Ansible developer. However, it's not always typical for an Ansible Collection author to be running Ansible from source but instead from a stable release, and to create Collections it is not necessary to run Ansible from source. Therefore, when references of dealing with `ansible-test` binary paths, command completion, or environment variables are presented throughout the :ref:`developing_testing` documentation; keep in mind that it is not needed for Ansible Collection Testing because the act of installing the stable release of Ansible containing `ansible-test` is expected to setup those things for you.
 
 .. _meta_runtime_yml:
 
diff --git a/docs/docsite/rst/dev_guide/developing_core.rst b/docs/docsite/rst/dev_guide/developing_core.rst
index a6c8bfe490..ce8b95ece4 100644
--- a/docs/docsite/rst/dev_guide/developing_core.rst
+++ b/docs/docsite/rst/dev_guide/developing_core.rst
@@ -2,7 +2,7 @@
 Developing ``ansible-core``
 ***************************
 
-Although ``ansible-core`` (the code hosted in the `ansible/ansible repository <https://github.com/ansible/ansible>`_ on GitHub) includes a few plugins that can be swapped out via playbook directives or configuration, much of the code there is not modular.  The documents here give insight into how the parts of ``ansible-core`` work together.
+Although ``ansible-core`` (the code hosted in the `ansible/ansible repository <https://github.com/ansible/ansible>`_ on GitHub) includes a few plugins that can be swapped out by the playbook directives or configuration, much of the code there is not modular.  The documents here give insight into how the parts of ``ansible-core`` work together.
 
 .. toctree::
    :maxdepth: 1
diff --git a/docs/docsite/rst/dev_guide/developing_inventory.rst b/docs/docsite/rst/dev_guide/developing_inventory.rst
index 8cc66aadd0..d2ecc1f589 100644
--- a/docs/docsite/rst/dev_guide/developing_inventory.rst
+++ b/docs/docsite/rst/dev_guide/developing_inventory.rst
@@ -7,7 +7,7 @@ Developing dynamic inventory
 Ansible can pull inventory information from dynamic sources, including cloud sources, by using the supplied :ref:`inventory plugins <inventory_plugins>`. For details about how to pull inventory information, see :ref:`dynamic_inventory`. If the source you want is not currently covered by existing plugins, you can create your own inventory plugin as with any other plugin type.
 
 In previous versions, you had to create a script or program that could output JSON in the correct format when invoked with the proper arguments.
-You can still use and write inventory scripts, as we ensured backwards compatibility via the :ref:`script inventory plugin <script_inventory>`
+You can still use and write inventory scripts, as we ensured backwards compatibility through the :ref:`script inventory plugin <script_inventory>`
 and there is no restriction on the programming language used.
 If you choose to write a script, however, you will need to implement some features yourself such as caching, configuration management, dynamic variable and group composition, and so on.
 If you use :ref:`inventory plugins <inventory_plugins>` instead, you can use the Ansible codebase and add these common features automatically.
@@ -228,7 +228,7 @@ Before using the cache plugin, you must retrieve a unique cache key by using the
         self.load_cache_plugin()
         cache_key = self.get_cache_key(path)
 
-Now that you've enabled caching, loaded the correct plugin, and retrieved a unique cache key, you can set up the flow of data between the cache and your inventory using the ``cache`` parameter of the ``parse`` method. This value comes from the inventory manager and indicates whether the inventory is being refreshed (such as via ``--flush-cache`` or the meta task ``refresh_inventory``). Although the cache shouldn't be used to populate the inventory when being refreshed, the cache should be updated with the new inventory if the user has enabled caching. You can use ``self._cache`` like a dictionary. The following pattern allows refreshing the inventory to work in conjunction with caching.
+Now that you've enabled caching, loaded the correct plugin, and retrieved a unique cache key, you can set up the flow of data between the cache and your inventory using the ``cache`` parameter of the ``parse`` method. This value comes from the inventory manager and indicates whether the inventory is being refreshed (such as by the ``--flush-cache`` or the meta task ``refresh_inventory``). Although the cache shouldn't be used to populate the inventory when being refreshed, the cache should be updated with the new inventory if the user has enabled caching. You can use ``self._cache`` like a dictionary. The following pattern allows refreshing the inventory to work in conjunction with caching.
 
 .. code-block:: python
 
diff --git a/docs/docsite/rst/dev_guide/developing_modules_checklist.rst b/docs/docsite/rst/dev_guide/developing_modules_checklist.rst
index cee9a3a813..292bb9061f 100644
--- a/docs/docsite/rst/dev_guide/developing_modules_checklist.rst
+++ b/docs/docsite/rst/dev_guide/developing_modules_checklist.rst
@@ -31,7 +31,7 @@ To contribute a module to most Ansible collections, you must:
 
 Additional requirements may apply for certain collections. Review the individual collection repositories for more information.
 
-Please make sure your module meets these requirements before you submit your PR/proposal. If you have questions, reach out via the ``#ansible-devel`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat <https://libera.chat>`_) or the `Ansible development mailing list <https://groups.google.com/group/ansible-devel>`_.
+Please make sure your module meets these requirements before you submit your PR/proposal. If you have questions, reach out by using the ``#ansible-devel`` chat channel (using Matrix at ansible.im or using IRC at `irc.libera.chat <https://libera.chat>`_) or the `Ansible development mailing list <https://groups.google.com/group/ansible-devel>`_.
 
 Contributing to Ansible: subjective requirements
 ================================================
diff --git a/docs/docsite/rst/dev_guide/developing_modules_general_windows.rst b/docs/docsite/rst/dev_guide/developing_modules_general_windows.rst
index 4316e8135e..4b742a2c52 100644
--- a/docs/docsite/rst/dev_guide/developing_modules_general_windows.rst
+++ b/docs/docsite/rst/dev_guide/developing_modules_general_windows.rst
@@ -168,7 +168,7 @@ When creating a new module there are a few things to keep in mind:
 - Avoid using try/catch statements over a large code block, rather use them for individual calls so the error message can be more descriptive
 - Try and catch specific exceptions when using try/catch statements
 - Avoid using PSCustomObjects unless necessary
-- Look for common functions in ``./lib/ansible/module_utils/powershell/`` and use the code there instead of duplicating work. These can be imported by adding the line ``#Requires -Module *`` where * is the filename to import, and will be automatically included with the module code sent to the Windows target when run via Ansible
+- Look for common functions in ``./lib/ansible/module_utils/powershell/`` and use the code there instead of duplicating work. These can be imported by adding the line ``#Requires -Module *`` where * is the filename to import, and will be automatically included with the module code sent to the Windows target when run through Ansible
 - As well as PowerShell module utils, C# module utils are stored in ``./lib/ansible/module_utils/csharp/`` and are automatically imported in a module execution if the line ``#AnsibleRequires -CSharpUtil *`` is present
 - C# and PowerShell module utils achieve the same goal but C# allows a developer to implement low level tasks, such as calling the Win32 API, and can be faster in some cases
 - Ensure the code runs under Powershell v3 and higher on Windows Server 2012 and higher; if higher minimum Powershell or OS versions are required, ensure the documentation reflects this clearly
diff --git a/docs/docsite/rst/dev_guide/developing_plugins.rst b/docs/docsite/rst/dev_guide/developing_plugins.rst
index dbf516ffa9..d1f8e82fe8 100644
--- a/docs/docsite/rst/dev_guide/developing_plugins.rst
+++ b/docs/docsite/rst/dev_guide/developing_plugins.rst
@@ -79,7 +79,7 @@ To access the configuration settings in your plugin, use ``self.get_option(<opti
 
 Configuration sources follow the precedence rules for values in Ansible. When there are multiple values from the same category, the value defined last takes precedence. For example, in the above configuration block, if both ``name_of_ansible_var`` and ``name_of_second_var`` are defined, the value of the ``option_name`` option will be the value of ``name_of_second_var``. Refer to :ref:`general_precedence_rules` for further information.
 
-Plugins that support embedded documentation (see :ref:`ansible-doc` for the list) should include well-formed doc strings. If you inherit from a plugin, you must document the options it takes, either via a documentation fragment or as a copy. See :ref:`module_documenting` for more information on correct documentation. Thorough documentation is a good idea even if you're developing a plugin for local use.
+Plugins that support embedded documentation (see :ref:`ansible-doc` for the list) should include well-formed doc strings. If you inherit from a plugin, you must document the options it takes, either through a documentation fragment or as a copy. See :ref:`module_documenting` for more information on correct documentation. Thorough documentation is a good idea even if you're developing a plugin for local use.
 
 Developing particular plugin types
 ==================================
@@ -160,7 +160,7 @@ Cache plugins
 
 Cache plugins store gathered facts and data retrieved by inventory plugins.
 
-Import cache plugins using the cache_loader so you can use ``self.set_options()`` and ``self.get_option(<option_name>)``. If you import a cache plugin directly in the code base, you can only access options via ``ansible.constants``, and you break the cache plugin's ability to be used by an inventory plugin.
+Import cache plugins using the cache_loader so you can use ``self.set_options()`` and ``self.get_option(<option_name>)``. If you import a cache plugin directly in the code base, you can only access options by the ``ansible.constants``, and you break the cache plugin's ability to be used by an inventory plugin.
 
 .. code-block:: python
 
@@ -287,7 +287,7 @@ Note that the ``CALLBACK_VERSION`` and ``CALLBACK_NAME`` definitions are require
 
 For example callback plugins, see the source code for the `callback plugins included with Ansible Core <https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/callback>`_
 
-New in ansible-core 2.11, callback plugins are notified (via ``v2_playbook_on_task_start``) of :ref:`meta<meta_module>` tasks. By default, only explicit ``meta`` tasks that users list in their plays are sent to callbacks.
+New in ansible-core 2.11, callback plugins are notified (by the ``v2_playbook_on_task_start``) of :ref:`meta<meta_module>` tasks. By default, only explicit ``meta`` tasks that users list in their plays are sent to callbacks.
 
 There are also some tasks which are generated internally and implicitly at various points in execution. Callback plugins can opt-in to receiving these implicit tasks as well, by setting ``self.wants_implicit_tasks = True``. Any ``Task`` object received by a callback hook will have an ``.implicit`` attribute, which can be consulted to determine whether the ``Task`` originated from within Ansible, or explicitly by the user.
 
@@ -342,7 +342,7 @@ You can see the details for inventory plugins in the :ref:`developing_inventory`
 Lookup plugins
 --------------
 
-Lookup plugins pull in data from external data stores. Lookup plugins can be used within playbooks both for looping --- playbook language constructs like ``with_fileglob`` and ``with_items`` are implemented via lookup plugins --- and to return values into a variable or parameter.
+Lookup plugins pull in data from external data stores. Lookup plugins can be used within playbooks both for looping --- playbook language constructs like ``with_fileglob`` and ``with_items`` are implemented through lookup plugins --- and to return values into a variable or parameter.
 
 Lookup plugins are expected to return lists, even if just a single element.
 
diff --git a/docs/docsite/rst/dev_guide/developing_program_flow_modules.rst b/docs/docsite/rst/dev_guide/developing_program_flow_modules.rst
index 4e50171fdf..82ffaf3c19 100644
--- a/docs/docsite/rst/dev_guide/developing_program_flow_modules.rst
+++ b/docs/docsite/rst/dev_guide/developing_program_flow_modules.rst
@@ -328,7 +328,7 @@ importing a module. This lets Ansible run both the wrapper script and the module
           Python module into the Python interpreter on the remote node. Python
           understands scripts on stdin but does not understand zip files.
 
-    * Prior to Ansible 2.7, the module was executed via a second Python interpreter instead of being
+    * Prior to Ansible 2.7, the module was executed by a second Python interpreter instead of being
       executed inside of the same process. This change was made once Python-2.4 support was dropped
       to speed up module execution.
 
@@ -513,14 +513,14 @@ Ansible can transfer a module to a remote machine in one of two ways:
 Pipelining only works with modules written in Python at this time because
 Ansible only knows that Python supports this mode of operation. Supporting
 pipelining means that whatever format the module payload takes before being
-sent over the wire must be executable by Python via stdin.
+sent over the wire must be executable by Python through stdin.
 
 .. _flow_args_over_stdin:
 
 Why pass args over stdin?
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
-Passing arguments via stdin was chosen for the following reasons:
+Passing arguments through stdin was chosen for the following reasons:
 
 * When combined with :ref:`ANSIBLE_PIPELINING`, this keeps the module's arguments from
   temporarily being saved onto disk on the remote machine. This makes it
@@ -818,7 +818,7 @@ The following are optional arguments for ``AnsibleModule()``:
 
   In this example, if the user specifies ``state=present``, at least one of the options ``path`` and ``content`` must be supplied (or both). To make sure that precisely one can be specified, combine ``required_if`` with ``mutually_exclusive``.
 
-  On the other hand, if ``force`` (a boolean parameter) is set to ``true``, ``yes`` etc., both ``force_reason`` and ``force_code`` must be specified.
+  On the other hand, if ``force`` (a boolean parameter) is set to ``true``, ``yes`` and so on, both ``force_reason`` and ``force_code`` must be specified.
 
 :required_by:
 
diff --git a/docs/docsite/rst/dev_guide/testing/sanity/future-import-boilerplate.rst b/docs/docsite/rst/dev_guide/testing/sanity/future-import-boilerplate.rst
index 9d150e1fe5..658ef06444 100644
--- a/docs/docsite/rst/dev_guide/testing/sanity/future-import-boilerplate.rst
+++ b/docs/docsite/rst/dev_guide/testing/sanity/future-import-boilerplate.rst
@@ -8,7 +8,7 @@ comment header:
 
     from __future__ import (absolute_import, division, print_function)
 
-This uses Python 3 semantics for absolute vs relative imports, division, and print.  By doing this,
+This uses Python 3 semantics for absolute versus relative imports, division, and print.  By doing this,
 we can write code which is portable between Python 2 and Python 3 by following the Python 3 semantics.
 
 
diff --git a/docs/docsite/rst/dev_guide/testing/sanity/no-unicode-literals.rst b/docs/docsite/rst/dev_guide/testing/sanity/no-unicode-literals.rst
index c4f3586a73..f8ca1d2c54 100644
--- a/docs/docsite/rst/dev_guide/testing/sanity/no-unicode-literals.rst
+++ b/docs/docsite/rst/dev_guide/testing/sanity/no-unicode-literals.rst
@@ -8,7 +8,7 @@ problems with it are:
   a byte string or text string.  The programmer has to first check the top of the file to see if the
   import is there.
 * It removes the ability to define native strings (a string which should be a byte string on python2
-  and a text string on python3) via a string literal.
+  and a text string on python3) by a string literal.
 * It makes for more context switching.  A programmer could be reading one file which has
   `unicode_literals` and know that bare string literals are text strings but then switch to another
   file (perhaps tracing program execution into a third party library) and have to switch their
diff --git a/docs/docsite/rst/dev_guide/testing_integration.rst b/docs/docsite/rst/dev_guide/testing_integration.rst
index 8426cd8e7d..b335826119 100644
--- a/docs/docsite/rst/dev_guide/testing_integration.rst
+++ b/docs/docsite/rst/dev_guide/testing_integration.rst
@@ -122,7 +122,7 @@ and enable PowerShell Remoting to continue.
 Running these tests may result in changes to your Windows host, so don't run
 them against a production/critical Windows environment.
 
-Enable PowerShell Remoting (run on the Windows host via Remote Desktop):
+Enable PowerShell Remoting (run on the Windows host by a Remote Desktop):
 
 .. code-block:: shell-session
 
diff --git a/docs/docsite/rst/dev_guide/testing_integration_legacy.rst b/docs/docsite/rst/dev_guide/testing_integration_legacy.rst
index 02c88bb136..115fde6c93 100644
--- a/docs/docsite/rst/dev_guide/testing_integration_legacy.rst
+++ b/docs/docsite/rst/dev_guide/testing_integration_legacy.rst
@@ -85,7 +85,7 @@ has lambda basic execution privileges.
 Running Tests
 =============
 
-The tests are invoked via a ``Makefile``.
+The tests are invoked through the ``Makefile``.
 
 If you haven't already got Ansible available use the local checkout by doing:
 
diff --git a/docs/docsite/rst/os_guide/windows_faq.rst b/docs/docsite/rst/os_guide/windows_faq.rst
index eee2fbea30..9732572326 100644
--- a/docs/docsite/rst/os_guide/windows_faq.rst
+++ b/docs/docsite/rst/os_guide/windows_faq.rst
@@ -215,8 +215,8 @@ The value for ``ansible_shell_type`` should either be ``cmd`` or ``powershell``.
 Use ``cmd`` if the ``DefaultShell`` has not been configured on the SSH service
 and ``powershell`` if that has been set as the ``DefaultShell``.
 
-Why is connecting to a Windows host via SSH failing?
-````````````````````````````````````````````````````
+Why is connecting to a Windows host through SSH failing?
+````````````````````````````````````````````````````````
 Unless you are using ``Win32-OpenSSH`` as described above, you must connect to
 Windows hosts using :ref:`windows_winrm`. If your Ansible output indicates that
 SSH was used, either you did not set the connection vars properly or the host is not inheriting them correctly.
diff --git a/docs/docsite/rst/os_guide/windows_performance.rst b/docs/docsite/rst/os_guide/windows_performance.rst
index 50fd18e125..c922b4d9ed 100644
--- a/docs/docsite/rst/os_guide/windows_performance.rst
+++ b/docs/docsite/rst/os_guide/windows_performance.rst
@@ -48,7 +48,7 @@ to pre-emptively create native images for the assemblies that PowerShell relies
 Fix high-CPU-on-boot for VMs/cloud instances
 --------------------------------------------
 If you are creating golden images to spawn instances from, you can avoid a disruptive
-high CPU task near startup via `processing the ngen queue <https://docs.microsoft.com/en-us/dotnet/framework/tools/ngen-exe-native-image-generator#native-image-service>`_
+high CPU task near startup through `processing the ngen queue <https://docs.microsoft.com/en-us/dotnet/framework/tools/ngen-exe-native-image-generator#native-image-service>`_
 within your golden image creation, if you know the CPU types won't change between
 golden image build process and runtime.
 
diff --git a/docs/docsite/rst/os_guide/windows_usage.rst b/docs/docsite/rst/os_guide/windows_usage.rst
index 687b59fa97..0e76646efa 100644
--- a/docs/docsite/rst/os_guide/windows_usage.rst
+++ b/docs/docsite/rst/os_guide/windows_usage.rst
@@ -35,12 +35,12 @@ Below are some examples of using all three options to install 7-Zip:
 .. code-block:: yaml+jinja
 
     # Install/uninstall with chocolatey
-    - name: Ensure 7-Zip is installed via Chocolatey
+    - name: Ensure 7-Zip is installed through Chocolatey
       win_chocolatey:
         name: 7zip
         state: present
 
-    - name: Ensure 7-Zip is not installed via Chocolatey
+    - name: Ensure 7-Zip is not installed through Chocolatey
       win_chocolatey:
         name: 7zip
         state: absent
@@ -51,12 +51,12 @@ Below are some examples of using all three options to install 7-Zip:
         url: https://www.7-zip.org/a/7z1701-x64.msi
         dest: C:\temp\7z.msi
 
-    - name: Ensure 7-Zip is installed via win_package
+    - name: Ensure 7-Zip is installed through win_package
       win_package:
         path: C:\temp\7z.msi
         state: present
 
-    - name: Ensure 7-Zip is not installed via win_package
+    - name: Ensure 7-Zip is not installed through win_package
       win_package:
         path: C:\temp\7z.msi
         state: absent
@@ -72,11 +72,11 @@ Below are some examples of using all three options to install 7-Zip:
         name: HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{23170F69-40C1-2702-1701-000001000000}
       register: 7zip_installed
 
-    - name: Ensure 7-Zip is installed via win_command
+    - name: Ensure 7-Zip is installed through win_command
       win_command: C:\Windows\System32\msiexec.exe /i C:\temp\7z.msi /qn /norestart
       when: 7zip_installed.exists == false
 
-    - name: Ensure 7-Zip is uninstalled via win_command
+    - name: Ensure 7-Zip is uninstalled through win_command
       win_command: C:\Windows\System32\msiexec.exe /x {23170F69-40C1-2702-1701-000001000000} /qn /norestart
       when: 7zip_installed.exists == true
 
diff --git a/docs/docsite/rst/os_guide/windows_winrm.rst b/docs/docsite/rst/os_guide/windows_winrm.rst
index fef54ce844..dc95e8e095 100644
--- a/docs/docsite/rst/os_guide/windows_winrm.rst
+++ b/docs/docsite/rst/os_guide/windows_winrm.rst
@@ -341,28 +341,28 @@ Some system dependencies that must be installed prior to using Kerberos. The scr
 
 .. code-block:: shell
 
-    # Via Yum (RHEL/Centos/Fedora for the older version)
+    # Through Yum (RHEL/Centos/Fedora for the older version)
     yum -y install gcc python-devel krb5-devel krb5-libs krb5-workstation
 
-    # Via DNF (RHEL/Centos/Fedora for the newer version)
+    # Through DNF (RHEL/Centos/Fedora for the newer version)
     dnf -y install gcc python3-devel krb5-devel krb5-libs krb5-workstation
 
-    # Via Apt (Ubuntu)
+    # Through Apt (Ubuntu)
     sudo apt-get install python-dev libkrb5-dev krb5-user
 
-    # Via Portage (Gentoo)
+    # Through Portage (Gentoo)
     emerge -av app-crypt/mit-krb5
     emerge -av dev-python/setuptools
 
-    # Via Pkg (FreeBSD)
+    # Through Pkg (FreeBSD)
     sudo pkg install security/krb5
 
-    # Via OpenCSW (Solaris)
+    # Through OpenCSW (Solaris)
     pkgadd -d http://get.opencsw.org/now
     /opt/csw/bin/pkgutil -U
     /opt/csw/bin/pkgutil -y -i libkrb5_3
 
-    # Via Pacman (Arch Linux)
+    # Through Pacman (Arch Linux)
     pacman -S krb5
 
 
@@ -441,7 +441,7 @@ expiration. The temporary credential caches are deleted after each task
 completes and will not interfere with the default credential cache.
 
 To disable automatic ticket management, set ``ansible_winrm_kinit_mode=manual``
-via the inventory.
+through the inventory.
 
 Automatic ticket management requires a standard ``kinit`` binary on the control
 host system path. To specify a different location or binary name, set the
@@ -678,7 +678,7 @@ When setting up the inventory, the following variables are required:
     # ansible-vault edit group_vars/windows.yml
     ansible_connection: winrm
 
-    # May also be passed on the command-line via --user
+    # May also be passed on the command-line through --user
     ansible_user: Administrator
 
     # May also be supplied at runtime with --ask-pass
diff --git a/docs/docsite/rst/reference_appendices/YAMLSyntax.rst b/docs/docsite/rst/reference_appendices/YAMLSyntax.rst
index d72d31628c..f80e57c561 100644
--- a/docs/docsite/rst/reference_appendices/YAMLSyntax.rst
+++ b/docs/docsite/rst/reference_appendices/YAMLSyntax.rst
@@ -74,8 +74,8 @@ These are called "Flow collections".
 
 Ansible doesn't really use these too much, but you can also specify a :ref:`boolean value <playbooks_variables>` (true/false) in several forms::
 
-    create_key: yes
-    needs_agent: no
+    create_key: true
+    needs_agent: false
     knows_oop: True
     likes_emacs: TRUE
     uses_cvs: false
diff --git a/docs/docsite/rst/reference_appendices/faq.rst b/docs/docsite/rst/reference_appendices/faq.rst
index feeb99bdac..611fb0ba1f 100644
--- a/docs/docsite/rst/reference_appendices/faq.rst
+++ b/docs/docsite/rst/reference_appendices/faq.rst
@@ -795,14 +795,14 @@ and backups, which most file based modules also support:
 
         - name: run validation, this will change a lot as needed. We assume it returns an error when not passing, use `failed_when` if otherwise.
           shell: run_validation_commmand
-          become: yes
+          become: true
           become_user: requiredbyapp
           environment:
             WEIRD_REQUIREMENT: 1
      rescue:
         - name: restore backup file to original, in the hope the previous configuration was working.
           copy:
-             remote_src: yes
+             remote_src: true
              dest: /x/y/z
              src: "{{ updated['backup_file'] }}"
      always:
diff --git a/docs/docsite/rst/reference_appendices/general_precedence.rst b/docs/docsite/rst/reference_appendices/general_precedence.rst
index 3fbc98b2b7..cf347ea903 100644
--- a/docs/docsite/rst/reference_appendices/general_precedence.rst
+++ b/docs/docsite/rst/reference_appendices/general_precedence.rst
@@ -101,7 +101,7 @@ When set in a playbook, variables follow the same inheritance rules as playbook
 
    - hosts: cloud
      gather_facts: false
-     become: yes
+     become: true
      vars:
        ansible_become_user: admin
      tasks:
diff --git a/docs/docsite/rst/reference_appendices/test_strategies.rst b/docs/docsite/rst/reference_appendices/test_strategies.rst
index 9577bcd2e3..09a3d73c05 100644
--- a/docs/docsite/rst/reference_appendices/test_strategies.rst
+++ b/docs/docsite/rst/reference_appendices/test_strategies.rst
@@ -31,7 +31,7 @@ things in your playbooks.
      - ansible.builtin.service:
          name: foo
          state: started
-         enabled: yes
+         enabled: true
 
 If you think the service may not be started, the best thing to do is request it to be started.  If the service fails to start, Ansible
 will yell appropriately. (This should not be confused with whether the service is doing something functional, which we'll show more about how to
@@ -55,7 +55,7 @@ want certain steps to execute in normal mode even when the ``--check`` flag is u
 
    tasks:
      - ansible.builtin.script: verify.sh
-       check_mode: no
+       check_mode: false
 
 Modules That Are Useful for Testing
 ```````````````````````````````````