docs: replace latin terms with english in the reference_appendices (#79010)

docs/docsite/rst/reference_appendices/faq.rst

@@ -166,10 +166,10 @@ want on the system if :command:`/usr/bin/python` on your system does not point t
 Python interpreter.
 
 Some platforms may only have Python 3 installed by default. If it is not installed as
-:command:`/usr/bin/python`, you will need to configure the path to the interpreter via
+:command:`/usr/bin/python`, you will need to configure the path to the interpreter through
 ``ansible_python_interpreter``. Although most core modules will work with Python 3, there may be some
 special purpose ones which do not or you may encounter a bug in an edge case. As a temporary
-workaround you can install Python 2 on the managed host and configure Ansible to use that Python via
+workaround you can install Python 2 on the managed host and configure Ansible to use that Python through
 ``ansible_python_interpreter``. If there's no mention in the module's documentation that the module
 requires Python 2, you can also report a bug on our `bug tracker
 <https://github.com/ansible/ansible/issues>`_ so that the incompatibility can be fixed in a future release.
@@ -223,7 +223,7 @@ If you want to run under Python 3 instead of Python 2 you may want to change tha
     $ source ./ansible/bin/activate
     $ pip install ansible
 
-If you need to use any libraries which are not available via pip (for instance, SELinux Python
+If you need to use any libraries which are not available through pip (for instance, SELinux Python
 bindings on systems such as Red Hat Enterprise Linux or Fedora that have SELinux enabled), then you
 need to install them into the virtualenv. There are two methods:
 
@@ -299,7 +299,7 @@ There are a few common errors that one might run into when trying to execute Ans
 
   To get around this limitation, download and install a later version of `python for z/OS <https://www.rocketsoftware.com/zos-open-source>`_ (2.7.13 or 3.6.1) that represents strings internally as ASCII. Version 2.7.13 is verified to work.
 
-* When ``pipelining = False`` in `/etc/ansible/ansible.cfg` then Ansible modules are transferred in binary mode via sftp however execution of python fails with
+* When ``pipelining = False`` in `/etc/ansible/ansible.cfg` then Ansible modules are transferred in binary mode through sftp however execution of python fails with
 
   .. error::
       SyntaxError: Non-UTF-8 code starting with \'\\x83\' in file /a/user1/.ansible/tmp/ansible-tmp-1548232945.35-274513842609025/AnsiballZ_stat.py on line 1, but no encoding declared; see https://python.org/dev/peps/pep-0263/ for details
@@ -333,7 +333,7 @@ It is known that it will not correctly expand the default tmp directory Ansible
 If you see module failures, this is likely the problem.
 The simple workaround is to set ``remote_tmp`` to a path that will expand correctly (see documentation of the shell plugin you are using for specifics).
 
-For example, in the ansible config file (or via environment variable) you can set::
+For example, in the ansible config file (or through environment variable) you can set::
 
     remote_tmp=$HOME/.ansible/tmp
 
@@ -449,7 +449,7 @@ How do I access a variable name programmatically?
 +++++++++++++++++++++++++++++++++++++++++++++++++
 
 An example may come up where we need to get the ipv4 address of an arbitrary interface, where the interface to be used may be supplied
-via a role parameter or other input. Variable names can be built by adding strings together using "~", like so:
+through a role parameter or other input. Variable names can be built by adding strings together using "~", like so:
 
 .. code-block:: jinja
 
@@ -526,7 +526,7 @@ For example, to access the value of the HOME environment variable on the managem
         local_home: "{{ lookup('env','HOME') }}"
 
 
-**On target machines :** Environment variables are available via facts in the ``ansible_env`` variable:
+**On target machines :** Environment variables are available through facts in the ``ansible_env`` variable:
 
 .. code-block:: jinja
 
@@ -678,7 +678,7 @@ The ``no_log`` attribute can also apply to an entire play::
 
 Though this will make the play somewhat difficult to debug. It's recommended that this
 be applied to single tasks only, once a playbook is completed. Note that the use of the
-``no_log`` attribute does not prevent data from being shown when debugging Ansible itself via
+``no_log`` attribute does not prevent data from being shown when debugging Ansible itself through
 the :envvar:`ANSIBLE_DEBUG` environment variable.
 
 
@@ -724,7 +724,7 @@ How do I get the original ansible_host when I delegate a task?
 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 
 As the documentation states, connection variables are taken from the ``delegate_to`` host so ``ansible_host`` is overwritten,
-but you can still access the original via ``hostvars``::
+but you can still access the original through ``hostvars``::
 
    original_host: "{{ hostvars[inventory_hostname]['ansible_host'] }}"
 

docs/docsite/rst/reference_appendices/general_precedence.rst

@@ -126,7 +126,7 @@ Variable scope: how long is a value available?
 
 Variable values set in a playbook exist only within the playbook object that defines them. These 'playbook object scope' variables are not available to subsequent objects, including other plays.
 
-Variable values associated directly with a host or group, including variables defined in inventory, by vars plugins, or using modules like :ref:`set_fact<set_fact_module>` and :ref:`include_vars<include_vars_module>`, are available to all plays. These 'host scope' variables are also available via the ``hostvars[]`` dictionary.
+Variable values associated directly with a host or group, including variables defined in inventory, by vars plugins, or using modules like :ref:`set_fact<set_fact_module>` and :ref:`include_vars<include_vars_module>`, are available to all plays. These 'host scope' variables are also available through the ``hostvars[]`` dictionary.
 
 .. _general_precedence_extra_vars:
 

docs/docsite/rst/reference_appendices/glossary.rst

@@ -126,12 +126,12 @@ when a term comes up on the mailing list.
         executing the internal :ref:`setup module <setup_module>` on the remote nodes.  You
         never have to call the setup module explicitly, it just runs, but it
         can be disabled to save time if it is not needed or you can tell
-        ansible to collect only a subset of the full facts via the
+        ansible to collect only a subset of the full facts through the
         ``gather_subset:`` option. For the convenience of users who are
         switching from other configuration management systems, the fact module
         will also pull in facts from the :program:`ohai` and :program:`facter`
         tools if they are installed.  These are fact libraries from Chef and
-        Puppet, respectively. (These may also be disabled via
+        Puppet, respectively. (These may also be disabled through
         ``gather_subset:``)
 
     Filter Plugin
@@ -233,7 +233,7 @@ when a term comes up on the mailing list.
     Inventory
         A file (by default, Ansible uses a simple INI format) that describes
         :term:`Hosts <Host>` and :term:`Groups <Group>` in Ansible.  Inventory
-        can also be provided via an :term:`Inventory Script` (sometimes called
+        can also be provided through an :term:`Inventory Script` (sometimes called
         an "External Inventory Script").
 
     Inventory Script
@@ -460,7 +460,7 @@ when a term comes up on the mailing list.
     SSH (Native)
         Native OpenSSH as an Ansible transport is specified with ``-c ssh``
         (or a config file, or a keyword in the :term:`playbook <playbooks>`)
-        and can be useful if wanting to login via Kerberized SSH or using SSH
+        and can be useful if wanting to login through Kerberized SSH or using SSH
         jump hosts, and so on.  In 1.2.1, ``ssh`` will be used by default if the
         OpenSSH binary on the control machine is sufficiently new.
         Previously, Ansible selected ``paramiko`` as a default.  Using

docs/docsite/rst/reference_appendices/python_3_support.rst

@@ -21,7 +21,7 @@ version of pip.  This will make the default :command:`/usr/bin/ansible` run with
       python version = 3.6.2 (default, Sep 22 2017, 08:28:09) [GCC 7.2.1 20170915 (Red Hat 7.2.1-2)]
 
 If you are running Ansible :ref:`from_source` and want to use Python 3 with your source checkout, run your
-command via ``python3``.  For example:
+command through ``python3``.  For example:
 
 .. code-block:: shell
 
@@ -32,7 +32,7 @@ command via ``python3``.  For example:
 .. note:: Individual Linux distribution packages may be packaged for Python2 or Python3.  When running from
     distro packages you'll only be able to use Ansible with the Python version for which it was
     installed.  Sometimes distros will provide a means of installing for several Python versions
-    (via a separate package or via some commands that are run after install).  You'll need to check
+    (through a separate package or through some commands that are run after install).  You'll need to check
     with your distro to see if that applies in your case.
 
 

docs/docsite/rst/reference_appendices/special_variables.rst

@@ -29,7 +29,7 @@ ansible_limit
     Contents of the ``--limit`` CLI option for the current execution of Ansible
 
 ansible_loop
-    A dictionary/map containing extended loop information when enabled via ``loop_control.extended``
+    A dictionary/map containing extended loop information when enabled through ``loop_control.extended``
 
 ansible_loop_var
     The name of the value provided to ``loop_control.loop_var``. Added in ``2.8``
@@ -58,7 +58,7 @@ ansible_play_hosts_all
 
 ansible_play_role_names
     The names of the roles currently imported into the current play. This list does **not** contain the role names that are
-    implicitly included via dependencies.
+    implicitly included through dependencies.
 
 ansible_playbook_python
     The path to the python interpreter being used by Ansible on the controller