From dccfbcca392bf461ceb0587331cff2e3e21f197d Mon Sep 17 00:00:00 2001 From: Thien-Thi Nguyen Date: Mon, 29 Nov 2021 03:36:02 -0500 Subject: 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 d96cdd58..6380f0ff 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 9d10045a..18015916 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 f6372dcc..7362642e 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 00250cd2..ff8fb645 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 c3c11f02..b7349bfc 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 f37e0548..b67a8ba2 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 5e22ae5f..4ef47b40 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 58a99066..24785082 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 2369c0a7..91bec2b1 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 5c40edf3..59eb1ba0 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 d56a51bd..be105d2b 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). -- cgit v1.2.3