[taler-docs] branch master updated: fix grammar: s/a/an/

[gnunet]

This is an automated email from the git hooks/post-receive script.

ttn pushed a commit to branch master
in repository docs.

The following commit(s) were added to refs/heads/master by this push:
     new dccfbcc  fix grammar: s/a/an/
dccfbcc is described below

commit dccfbcca392bf461ceb0587331cff2e3e21f197d
Author: Thien-Thi Nguyen <ttn@gnuvola.org>
AuthorDate: Mon Nov 29 03:36:02 2021 -0500

    fix grammar: s/a/an/
---
 core/api-merchant.rst                              |  4 ++--
 .../002-wallet-exchange-management.rst             |  2 +-
 .../015-merchant-backoffice-routing.rst            | 25 ++++++++++------------
 .../016-backoffice-order-management.rst            |  2 +-
 design-documents/023-taler-kyc.rst                 |  2 +-
 libeufin/api-nexus.rst                             |  2 +-
 libeufin/api-sandbox.rst                           |  2 +-
 manpages/taler-auditor-offline.1.rst               |  2 +-
 taler-developer-manual.rst                         | 10 ++++-----
 taler-exchange-manual.rst                          |  2 +-
 taler-exchange-setup-guide.rst                     |  4 ++--
 11 files changed, 27 insertions(+), 30 deletions(-)

diff --git a/core/api-merchant.rst b/core/api-merchant.rst
index d96cdd5..6380f0f 100644
--- a/core/api-merchant.rst
+++ b/core/api-merchant.rst
@@ -38,7 +38,7 @@ instance is used when no explicit instance is specified.  
Despite its name,
 this instance must be created after the installation.  In case *no* default
 instance is found - or its credentials got lost -, the administrator can use
 the default instance's rights by resorting on the ``--auth`` command line 
option,
-or by restarting the service by providing a environment variable called
+or by restarting the service by providing an environment variable called
 ``TALER_MERCHANT_TOKEN``.
 
 Each instance (default and others) has a base URL.  The resources under
@@ -3069,7 +3069,7 @@ The contract terms must have the following structure:
     extra?: any;
   }
 
-The wallet must select a exchange that either the merchant accepts directly by
+The wallet must select an exchange that either the merchant accepts directly by
 listing it in the exchanges array, or for which the merchant accepts an auditor
 that audits that exchange by listing it in the auditors array.
 
diff --git a/design-documents/002-wallet-exchange-management.rst 
b/design-documents/002-wallet-exchange-management.rst
index 9d10045..1801591 100644
--- a/design-documents/002-wallet-exchange-management.rst
+++ b/design-documents/002-wallet-exchange-management.rst
@@ -40,7 +40,7 @@ audited by a trusted auditor.
 An exchange might only be known the wallet temporarily.  For example,
 the wallet UI may allow the user to review the fee structure of an
 exchange before the wallet is permanently added to the wallet.
-Once a an exchange is either (a) marked as trusted or (b) used for a
+Once an exchange is either (a) marked as trusted or (b) used for a
 withdrawal operation, it is marked as permanent.
 
 Exchanges that are not permanent will be automatically be removed
diff --git a/design-documents/015-merchant-backoffice-routing.rst 
b/design-documents/015-merchant-backoffice-routing.rst
index f6372dc..7362642 100644
--- a/design-documents/015-merchant-backoffice-routing.rst
+++ b/design-documents/015-merchant-backoffice-routing.rst
@@ -6,16 +6,16 @@ Motivation
 ==========
 
 A well defined routing will allow users to share backoffice links pointing
-directly into instance pages (settings, orders, products, etc...) 
+directly into instance pages (settings, orders, products, etc...)
 
-The backoffice should load from the instance URL and then allow a internal
+The backoffice should load from the instance URL and then allow an internal
 routing of the views with the possibility to accessing them directly when
 sharing a link.
 
 This 3 definitions are going to be use in this document:
 
-* BACKOFFICE_URL as the url where the app is loaded. 
- 
+* BACKOFFICE_URL as the url where the app is loaded.
+
 * BACKEND_URL as the url where the merchant backend is.
 
 * INSTANCE the name of the instance being manage
@@ -27,13 +27,13 @@ Application Ready definition
 The application is considered ready after
 
 * the user tried to login.
-  
+
 * the application checked that the backend url points to a merchant backend
 
 * the merchant backend response successfully
 
 The backoffice test for ``$BACKEND_URL/config`` to define if the $BACKEND_URL 
is ok.
-The application can potentially test if the protocol or version matched. 
+The application can potentially test if the protocol or version matched.
 
 While the application is not ready, just the top navigation bar will be shown
 with a message in the left and the lang selection option.
@@ -58,7 +58,7 @@ Knowing that the $BACKEND_URL points to a correct merchant 
backend the SPA will
 check for ``$BACKEND_URL/management/instances``:
 
 * if Unauthorized ask for credentials
- 
+
 * if error check with the user
 
 * if not found, then url should end with ``/instances/$INSTANCE``. otherwise is
@@ -69,11 +69,11 @@ check for ``$BACKEND_URL/management/instances``:
 When a user access the SPA there are 3 scenarios possible:
 
 * **standard**: admin is false so BACKEND_URL points to a non-default instance.
-  standard features and links are shown 
+  standard features and links are shown
 
 * **admin**: admin is true so BACKEND_URL point to default instance. same as
   before and user can create and list instances with some additional links in
-  the sidebar. 
+  the sidebar.
 
 * **mimic**: admin is true and the request parameter "instance" is set 
$INSTANCE
   instance. BACKEND_URL point to default instance but the user is managing
@@ -99,7 +99,7 @@ parameter (like order id or product id) it should be 
accessible from the Sidebar
 If the user has admin access, this entry points are available:
 
  - /instances: Show the list of instances currently created
- - /instance/new: Show a instance creation form
+ - /instance/new: Show an instance creation form
 
 Where admin or not, there is also this entry points:
 
@@ -145,7 +145,7 @@ credentials or the backend url
 Not found
 ---------
 
-For any case that the backend respond 404 the application will render a 
+For any case that the backend respond 404 the application will render a
 custom not found page
 
 Default instance is missing
@@ -155,6 +155,3 @@ If the **user is admin** AND is loading the setting page 
(/update), product list
 (/products), order list (/orders) or transfer list (/transfers) AND **gets a
 404** it will tell the user that it need to create a default instance before
 proceeding.
-
- 
-
diff --git a/design-documents/016-backoffice-order-management.rst 
b/design-documents/016-backoffice-order-management.rst
index 00250cd..ff8fb64 100644
--- a/design-documents/016-backoffice-order-management.rst
+++ b/design-documents/016-backoffice-order-management.rst
@@ -35,7 +35,7 @@ Listing orders
 .. image:: ../backoffice-order-list.svg
   :width: 800
 
-4 tabs will be show for a easy access to common filter, click on any of this 
and
+4 tabs will be show for an easy access to common filter, click on any of this 
and
 search will reset all filter except date
 
 * paid (default)
diff --git a/design-documents/023-taler-kyc.rst 
b/design-documents/023-taler-kyc.rst
index c3c11f0..b7349bf 100644
--- a/design-documents/023-taler-kyc.rst
+++ b/design-documents/023-taler-kyc.rst
@@ -88,7 +88,7 @@ has the KYC status set to positive (unless KYC is disabled in 
the exchange
 configuration).
 
 To allow the wallet to do the KYC check if it is about to exceed a set balance
-threshold, we modify the ``/keys`` response to add a optional field
+threshold, we modify the ``/keys`` response to add an optional field
 ``wallet_balance_limit_without_kyc`` the wallet is allowed to hold in coins
 from this exchange without KYC.  If this field is absent, there is no limit.
 If the field is provided, a correct wallet must create a long-term
diff --git a/libeufin/api-nexus.rst b/libeufin/api-nexus.rst
index f37e054..b67a8ba 100644
--- a/libeufin/api-nexus.rst
+++ b/libeufin/api-nexus.rst
@@ -204,7 +204,7 @@ Test API
 
   **Response**
 
-  The successful case should respond with a ``200 OK`` and a empty JSON body.
+  The successful case should respond with a ``200 OK`` and an empty JSON body.
 
 
 Bank Accounts
diff --git a/libeufin/api-sandbox.rst b/libeufin/api-sandbox.rst
index 5e22ae5..4ef47b4 100644
--- a/libeufin/api-sandbox.rst
+++ b/libeufin/api-sandbox.rst
@@ -50,7 +50,7 @@ Current Sandbox API
   Give details of all the EBICS subscribers in the bank.
 
   POST /admin/ebics/bank-accounts
-  Create a *new* bank account and link it with a existing
+  Create a *new* bank account and link it with an existing
   EBICS subscriber.
 
   ** EBICS host management **
diff --git a/manpages/taler-auditor-offline.1.rst 
b/manpages/taler-auditor-offline.1.rst
index 58a9906..2478508 100644
--- a/manpages/taler-auditor-offline.1.rst
+++ b/manpages/taler-auditor-offline.1.rst
@@ -24,7 +24,7 @@ Description
 ===========
 
 **taler-auditor-offline** is a command-line tool to be used by an auditor to
-sign that he is aware of certain keys being used by a exchange. Using this
+sign that he is aware of certain keys being used by an exchange. Using this
 signature, the auditor affirms that he will verify that the exchange is
 properly accounting for coins of those denominations.  The tool takes a list
 of subcommands as arguments which are then processed sequentially.
diff --git a/taler-developer-manual.rst b/taler-developer-manual.rst
index 2369c0a..91bec2b 100644
--- a/taler-developer-manual.rst
+++ b/taler-developer-manual.rst
@@ -169,7 +169,7 @@ you can add the nightly package sources.
    # For Debian (bullseye)
    $ echo "deb https://deb.taler.net/apt-nightly bullseye-taler-nightly main" 
> /etc/apt/sources.list.d/taler.list
 
-   # Both: Install signing key for nightly packages 
+   # Both: Install signing key for nightly packages
    $ wget -O - https://taler.net/taler-systems-nightly.gpg.key | apt-key add -
 
 
@@ -381,7 +381,7 @@ Documentation Builder
 
 All the Taler documentation is built by the user ``docbuilder`` that
 runs a Buildbot worker.  The following commands set the ``docbuilder`` up,
-starting with a empty home directory.
+starting with an empty home directory.
 
 .. code-block:: console
 
@@ -403,7 +403,7 @@ Website Builder
 
 Taler Websites, ``www.taler.net`` and ``stage.taler.net``, are built by the
 user ``taler-websites`` by the means of a Buildbot worker.  The following
-commands set the ``taler-websites`` up, starting with a empty home directory.
+commands set the ``taler-websites`` up, starting with an empty home directory.
 
 .. code-block:: console
 
@@ -1129,7 +1129,7 @@ This chapter is a VERY ABSTRACT description of how 
testing is
 implemented in Taler, and in NO WAY wants to substitute the reading of
 the actual source code by the user.
 
-In Taler, a test case is a array of ``struct TALER_TESTING_Command``,
+In Taler, a test case is an array of ``struct TALER_TESTING_Command``,
 informally referred to as ``CMD``, that is iteratively executed by the
 testing interpreter. This latter is transparently initiated by the
 testing library.
@@ -1152,7 +1152,7 @@ CMDs: for example, CMD1 may create some key material and 
CMD2 needs this
 key material to encrypt data.
 
 The offering of internal values from CMD1 to CMD2 is made by *traits*. A
-trait is a ``struct TALER_TESTING_Trait``, and each CMD contains a array
+trait is a ``struct TALER_TESTING_Trait``, and each CMD contains an array
 of traits, that it offers via the public trait interface to other
 commands. The definition and filling of such array happens transparently
 to the test developer.
diff --git a/taler-exchange-manual.rst b/taler-exchange-manual.rst
index 5c40edf..59eb1ba 100644
--- a/taler-exchange-manual.rst
+++ b/taler-exchange-manual.rst
@@ -85,7 +85,7 @@ funds in an escrow account.
 
 Note that, given the technical burden (XML-based communications,
 additional cryptography, and a vast variety of standards) due to
-interact with banks, the exchange uses a intermediary system to talk
+interact with banks, the exchange uses an intermediary system to talk
 to its bank.  Such intermediary system abstracts the native banking
 protocol by exposing the *Taler Wire Gateway API*; this way, the exchange
 can conduct its banking operations in a simplified and JSON-based style.
diff --git a/taler-exchange-setup-guide.rst b/taler-exchange-setup-guide.rst
index d56a51b..be105d2 100644
--- a/taler-exchange-setup-guide.rst
+++ b/taler-exchange-setup-guide.rst
@@ -210,7 +210,7 @@ The deployment creates the following key locations in the 
system:
 Setup Linting
 =============
 
-The ``taler-wallet-cli`` package comes with a experimental tool that runs 
various
+The ``taler-wallet-cli`` package comes with an experimental tool that runs 
various
 checks on the current GNU Taler exchange deployment:
 
 .. code-block:: shell-session
@@ -610,7 +610,7 @@ and create payment initiations with a Taler wire gateway 
facade:
      facade.talerwiregateway.transfer
 
 ..
-  FIXME: The two commands above output a empty JSON object
+  FIXME: The two commands above output an empty JSON object
   when successful.  Possibly, we should suppress that (just like
   the other commands do).
 

-- 
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.