[taler-docs] branch master updated: fix typos

[gnunet]

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

grothoff pushed a commit to branch master
in repository docs.

The following commit(s) were added to refs/heads/master by this push:
     new 82c288c  fix typos
82c288c is described below

commit 82c288c2f2a4253836d11e16f8697380d3fb4864
Author: Christian Grothoff <christian@grothoff.org>
AuthorDate: Sun Oct 25 22:59:28 2020 +0100

    fix typos
---
 anastasis.rst                   | 4 ++--
 developers-manual.rst           | 6 +++---
 taler-auditor-manual.rst        | 6 +++---
 taler-exchange-manual.rst       | 4 ++--
 taler-merchant-api-tutorial.rst | 6 +++---
 taler-merchant-manual.rst       | 8 ++++----
 taler-nfc-guide.rst             | 2 +-
 7 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/anastasis.rst b/anastasis.rst
index f7232c5..74d5160 100644
--- a/anastasis.rst
+++ b/anastasis.rst
@@ -312,7 +312,7 @@ Anastasis server operators must be protected against 
denial-of-service attacks
 where an adversary attempts to exhaust operator's resources.  The API protects
 against these attacks by allowing operators to set fees for all
 operations. Furthermore, all data stored comes with an expiration logic, so an
-attacker cannot force servers to store data indefinitively.
+attacker cannot force servers to store data indefinitely.
 
 A second availability issue arises from strong adversaries that may be able to
 compute the account keys of some user.  While we assume that such an adversary
@@ -484,7 +484,7 @@ In the following, UUID is always defined and used according 
to `RFC 4122`_.
   :status 200 OK:
     The escrow provider responds with an EncryptedRecoveryDocument_ object.
   :status 304 Not modified:
-    The client requested the same ressource it already knows.
+    The client requested the same resource it already knows.
   :status 400 Bad request:
     The $ACCOUNT_PUB is not an EdDSA public key.
   :status 402 Payment Required:
diff --git a/developers-manual.rst b/developers-manual.rst
index c5f5b77..22d205f 100644
--- a/developers-manual.rst
+++ b/developers-manual.rst
@@ -965,7 +965,7 @@ Python for Scripting
 When using Python for writing small utilities, the following libraries
 are useful:
 
-* ``click`` for argument parsing (should be prefered over argparse)
+* ``click`` for argument parsing (should be preferred over argparse)
 * ``pathlib`` for path manipulation (part of the standard library)
 * ``subprocess`` for "shelling out" to other programs.  Prefer 
``subprocess.run``
   over the older APIs.
@@ -1314,7 +1314,7 @@ use when talking to end users or even system 
administrators.
   relative time
     method of keeping time in :term:`GNUnet` where the time is represented
     as a relative number of microseconds.  Thus, a relative time specifies
-    an offet or a duration, but not a date.  Called relative time in
+    an offset or a duration, but not a date.  Called relative time in
     contrast to :term:`absolute time`.
 
   recoup
@@ -1334,7 +1334,7 @@ use when talking to end users or even system 
administrators.
     making a payment with :term:`coins` to a :term:`merchant`.
 
   privacy policy
-    Statment of an operator how they will protect the privacy of users.
+    Statement of an operator how they will protect the privacy of users.
 
   proof
     Message that cryptographically demonstrates that a particular claim is 
correct.
diff --git a/taler-auditor-manual.rst b/taler-auditor-manual.rst
index 1d84d45..35f5a79 100644
--- a/taler-auditor-manual.rst
+++ b/taler-auditor-manual.rst
@@ -127,7 +127,7 @@ components:
    fail to be imported due to constraint violations, this is an immediate 
serious
    concern that must be addressed manually.  The software only verifies the 
content
    of a well-formed exchange database (well-formed with respect to SQL).
-   For now, the GNU Taler reference implemenation
+   For now, the GNU Taler reference implementation
    only supports Postgres, but the code could be easily extended to
    support another DBMS.
 
@@ -387,7 +387,7 @@ the exchange operator obtains a *blob* with the data about 
denomination keys
 that the exchange operator needs to get signed by every auditor the exchange
 wishes (or is forced to) work with.
 
-In a normal scenario, an auditor must have some secure business proces to
+In a normal scenario, an auditor must have some secure business process to
 receive the blob to sign (Website, manual delivery, ...).  Note that the
 blob does not contain confidential data, but signing the wrong keys would
 be fatal.  Given the blob, the auditor would sign it using:
@@ -596,7 +596,7 @@ Auditor implementation guide
 
 The auditor implementation is split into five main processes, called
 ``taler-helper-auditor-XXX``.  The split was done to realize the principle of
-least priviledge and to enable independent logic to be possibly run in
+least privilege and to enable independent logic to be possibly run in
 parallel.  Only the taler-wire-auditor must have (read-only) access to the
 exchange's bank account, the other components only need access to the
 database.
diff --git a/taler-exchange-manual.rst b/taler-exchange-manual.rst
index 6e4bae8..b156eb9 100644
--- a/taler-exchange-manual.rst
+++ b/taler-exchange-manual.rst
@@ -914,7 +914,7 @@ TALER_SIGNATURE_AUDITOR_EXCHANGE_KEYS purpose.
 .. [2]
    The current implementation does not make provisions for secret
    splitting. Still, the use of a hardware security module (HSM) for
-   protecting private keys is adviseable, so please contact the
+   protecting private keys is advisable, so please contact the
    developers for HSM integration support.
 
 .. [3]
@@ -937,7 +937,7 @@ and clients, or only launch the parallel clients (``-m``), 
for example for
 distributed testing over a network.
 
 For each *parallel* (``-p``) client, a number of *reserves* (``-r``) is first 
established by
-**transfering** money from a "user" account (42) to the Exchange's account
+**transferring** money from a "user" account (42) to the Exchange's account
 with the respective reserve public key as wire subject.  Next, the
 client will **withdraw** a *number of coins* (``-n``) from the reserve and
 **deposit** them. Additionally, a *fraction* (``-R``) of the dirty coins will 
then be
diff --git a/taler-merchant-api-tutorial.rst b/taler-merchant-api-tutorial.rst
index 39cf36d..823a675 100644
--- a/taler-merchant-api-tutorial.rst
+++ b/taler-merchant-api-tutorial.rst
@@ -377,7 +377,7 @@ are recognized in the JSON request object:
 -  amount: Amount that should be given to the visitor as a tip.
 
 -  instance: Merchant instance that grants the tip (each instance may
-   have its own independend tipping funds configured).
+   have its own independent tipping funds configured).
 
 -  justification: Description of why the tip was granted. Human-readable
    text not exposed to the customer, but used by the Back Office.
@@ -533,14 +533,14 @@ signature (``session_sig``). This signature certifies 
that the wallet
 showed a payment receipt for the respective order in the current
 session. cookie
 
-Session-bound payments are triggerd by passing the ``session_id``
+Session-bound payments are triggered by passing the ``session_id``
 parameter to the ``/check-payment`` endpoint. The wallet will then
 redirect to the fulfillment page, but include an additional
 ``session_sig`` parameter. The frontend can query ``/check-payment``
 with both the ``session_id`` and the ``session_sig`` to verify that the
 signature is correct.
 
-The last session ID that was successfuly used to prove that the payment
+The last session ID that was successfully used to prove that the payment
 receipt is in the user’s wallet is also available as ``last_session_id``
 in the response to ``/check-payment``.
 
diff --git a/taler-merchant-manual.rst b/taler-merchant-manual.rst
index 6d14806..1e6e72a 100644
--- a/taler-merchant-manual.rst
+++ b/taler-merchant-manual.rst
@@ -87,7 +87,7 @@ components:
    to process financial transactions with Taler. This manual primarily
    describes how to install and configure this backend.
 -  A DBMS which stores the transaction history for the Taler backend.
-   For now, the GNU Taler reference implemenation only supports
+   For now, the GNU Taler reference implementation only supports
    Postgres, but the code could be easily extended to support another
    DBMS.  Please review the Postgres documentation for details on
    how to configure the database.
@@ -1100,7 +1100,7 @@ in a special “402 Payment Required” response inside the 
``X-Taler-Tip``
 header.
 
 The frontend should handle errors returned by the backend, such as
-missconfigured instances or a lack of remaining funds for tipping.
+misconfigured instances or a lack of remaining funds for tipping.
 
 .. _Picking-up-of-the-tip:
 
@@ -1336,7 +1336,7 @@ second gives the chance to leave some payments 
unaggregated, and also to
 use merchant instances other than the default (which is, actually, the
 one used by default by the tool).
 
-Note: the abilty of driving the aggregation policy is useful for testing
+Note: the ability of driving the aggregation policy is useful for testing
 the backoffice facility.
 
 Any subcommand is also equipped with the canonical ``--help`` option, so
@@ -1410,7 +1410,7 @@ layout:
    [PAYMENTS-GENERATOR]
 
    # The exchange used during the test: make sure the merchant backend
-   # being tested accpets this exchange.
+   # being tested accepts this exchange.
    # If the sysadmin wants, she can also install a local exchange
    # and test against it.
    EXCHANGE = https://exchange.demo.taler.net/
diff --git a/taler-nfc-guide.rst b/taler-nfc-guide.rst
index 88fa13d..8143387 100644
--- a/taler-nfc-guide.rst
+++ b/taler-nfc-guide.rst
@@ -241,7 +241,7 @@ NFC. In particular, only JSON request and response bodies 
are allowed.
 
 It is currently assumed that the requests and responses fit into one APDU 
frame.
 For devices with more limited maximum APDU sizes, additional TIDs for segmented
-tunnel requests/responsed may be defined in the future.
+tunnel requests/responses may be defined in the future.
 
 A request for tunneling is initiated with TID ``0x03`` and responded to with
 TID ``0x02`` (see tables above).  A tunneling request is identified by a

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