|author||Thien-Thi Nguyen <email@example.com>||2021-11-29 03:36:02 -0500|
|committer||Thien-Thi Nguyen <firstname.lastname@example.org>||2021-11-29 03:36:02 -0500|
fix grammar: s/a/an/
11 files changed, 27 insertions, 30 deletions
diff --git a/core/api-merchant.rst b/core/api-merchant.rst
index d96cdd5..6380f0f 100644
@@ -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
Each instance (default and others) has a base URL. The resources under
@@ -3069,7 +3069,7 @@ The contract terms must have the following structure:
-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
@@ -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
@@ -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
-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
diff --git a/design-documents/016-backoffice-order-management.rst b/design-documents/016-backoffice-order-management.rst
index 00250cd..ff8fb64 100644
@@ -35,7 +35,7 @@ Listing orders
.. image:: ../backoffice-order-list.svg
-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
@@ -88,7 +88,7 @@ has the KYC status set to positive (unless KYC is disabled in the exchange
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
@@ -204,7 +204,7 @@ Test API
- 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.
diff --git a/libeufin/api-sandbox.rst b/libeufin/api-sandbox.rst
index 5e22ae5..4ef47b4 100644
@@ -50,7 +50,7 @@ Current Sandbox API
Give details of all the EBICS subscribers in the bank.
- Create a *new* bank account and link it with a existing
+ Create a *new* bank account and link it with an existing
** EBICS host management **
diff --git a/manpages/taler-auditor-offline.1.rst b/manpages/taler-auditor-offline.1.rst
index 58a9906..2478508 100644
@@ -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
@@ -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
@@ -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
@@ -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
@@ -210,7 +210,7 @@ The deployment creates the following key locations in the system:
-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:
- 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).