[GNUnet-SVN] [taler-codeless] branch master updated: typos in doc

[gnunet]

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

shivam-kohli pushed a commit to branch master
in repository codeless.

The following commit(s) were added to refs/heads/master by this push:
     new 6f1b508  typos in doc
6f1b508 is described below

commit 6f1b508db9940fb09357b8901f1f2c9b0cc6ffcd
Author: shivam kohli <address@hidden>
AuthorDate: Thu Aug 9 10:32:02 2018 +0530

    typos in doc
---
 doc/codeless.texi | 111 +++++++++++++++++++++++++++---------------------------
 1 file changed, 55 insertions(+), 56 deletions(-)

diff --git a/doc/codeless.texi b/doc/codeless.texi
index 0a8b80c..ee9f3ec 100644
--- a/doc/codeless.texi
+++ b/doc/codeless.texi
@@ -86,12 +86,12 @@ regulation (such as GDPR).
 This tutorial targets system administrators who want to install and
 operate a GNU Taler Codeless Merchant.
 A component that sits between the seller's frontend and the GNU Taler 
-merchant backend. This component should has a web interface, where 
+merchant backend. This component should have a web interface, where
 payment buttons can be configured. Additional Component include 
 inventory management, where the seller can configure the available 
 stock for an item and will get notified when their stock runs low.
-Currently, to accept payments with GNU Taler, people have to write 
-their own code. By using this the merchant will be able to communicate 
+Currently, to accept payments with GNU Taler, people have to write
+their own code. By using this the merchant will be able to communicate
 with the merchant’s backend via a simple API.
 
 @section Architecture overview
@@ -105,21 +105,21 @@ The following three components has been included.
 @item A frontend which interacts with the customer's browser. The
   frontend enables the customer to place an order. Upon payment, 
   it redirects the user on the shipment detail form where the user
-  adds his shiment details. Moreover, the frontend is a complete portal 
-  where the merchant has the abality to create and manage his account.
-  He has the flexibilty to manage his inventory.
+  adds his shipment details. Moreover, the frontend is a complete portal
+  where the merchant has the ability to create and manage his account.
+  He has the flexibility to manage his inventory.
 @cindex Backend
address@hidden The backend of codeless payment is very roboust and can be easily
address@hidden The backend of codeless payment is very robust and can be easily
   extended as per the requirements. The backend provides a lot of operations
   namely manage incoming and outgoing inventory, service for handling,
-  payments, managing singup and singin for the merchant, and handle all the 
-  url requests. This tutorial will describe how to integrate such a component
+  payments, managing signup and singing for the merchant, and handle all the 
+  URL requests. This tutorial will describe how to integrate such a component
   to handle payments managed by Taler and also manage the inventory for the 
   merchant.
 @cindex Database
 @item A SQL which stores the order history for the Merchant backend and 
-  keeps a track of the inventory. For now, the reference implemenation only 
-  supports sqlite, but the code could be easily extended to support another 
DBMS
+  keeps a track of the inventory. For now, the reference implementation only 
+  supports SQLite, but the code could be easily extended to support another 
DBMS
 @end itemize
 
 The following image illustrates the various interactions of these key 
components:
@@ -185,25 +185,25 @@ The following image illustrates the database schema used 
for inventory tracking:
 The Merchant can add two types of inventory
 @itemize
 @item Digital Inventory
-  The seller can upload Digital Inventory (like a PDF or html page)
+  The seller can upload Digital Inventory (like a PDF or HTML page)
   via the codeless payments frontend, and the user can then purchase
   it and view the version hosted by the codeless payment frontend.
   A large number of uploading format is accepted. The content-type
-  of the uploaded file is determined by a self defined function in
-  the backend.The stock for digital purchases doesn't run out.
+  of the uploaded file is determined by a self-defined function in the
+  backend. The stock for digital purchases doesn't run out.
 @item Normal Product
-  In this kind of product the seller has a flexibilty to add any
-  product. While adding these inventory, the seller is promted to
+  In this kind of product, the seller has the flexibility to add any
+  product. While adding these inventory, the seller is prompted to
   add MinimumQuantity of Product that is required to be maintained
-  in the stock. Whenever the stoxks run below this limit the seller
-  would be notified(Curently this feature has not been added but 
-  soon email notification would be added). Whenever user purchases 
+  in the stock. Whenever the stocks run below this limit the seller
+  would be notified(Currently this feature has not been added but
+  soon email notification would be added). Whenever user purchases
   a product from the seller, after successful payment they will be
-  redirected to the fullfillment page. On the fullfillment page
+  redirected to the fulfilment page. On the fullfillment page
   the user can track his shipment. The status of the order is
-  updated by the merchant and on this basis the user is
-  updated about his shipment on the fullfillment page. For now there
-  are five paramters that have used for tracking.
+  updated by the merchant and on this basis, the user is
+  updated about his shipment on the fulfilment page. For now, there
+  are five parameters that have used for tracking.
 @end itemize
 
 
@@ -211,40 +211,40 @@ The Merchant can add two types of inventory
 @section Shipment Tracking
 
 Whenever user purchases a product from the seller, after successful
-payment they are redirected to the fullfillment page. For digital
-inventory the fullfillment page would be the direct display of the
-digital inventory(like pdf). But for actual product shipment tracking 
-makes sence. Therefore on the fullfillment page the user can track
+payment they are redirected to the fulfilment page. For digital
+inventory, the fulfilment page would be the direct display of the
+digital inventory(like pdf). But for actual product shipment tracking
+makes sense. Therefore on the fulfilment page, the user can track
 his shipment. The status of the order is updated by the merchant
-and on this basis the user is updated about his shipment of fullfillment
-page. For now there are five paramters that have used for tracking, but
+and on this basis, the user is updated about his shipment of fulfilment
+page. For now, there are five parameters that have used for tracking, but
 this is extensible and can be modified according to the requirement. The
 initial status of order is marked as 'Pre Processing'.
 
 @node Order Creation
 @section Order Creation
 
-The pay_url that is used while making contract is handled by the 
+The pay_url that is used while making the contract is handled by the
 codeless payment backend. While handling this function the crsf
-token is exempted and this function returns the json request. The 
+token is exempted and this function returns the json request. The
 order creation depends on the json format. If the json response status
 is 200 only then an order will be created and also the quantity of the
 same product is used to update the inventory on hand. For digital
-inventory the inventory on hand remains zero. Untill and Unless a response
-code of 200 is recieved, the inventory won't be updated. Similarly, all
+inventory, the inventory on hand remains zero. Until and Unless a response
+code of 200 is received, the inventory won't be updated. Similarly, all
 the orders purchased are added in the Order table in the database. The
-status for each order has to be updated buy the Merchant manually. The initial
-status of order is marked as 'Pre Processing'.
+status for each order has to be updated by the Merchant manually. The initial
+status of the order is marked as 'Pre Processing'.
 
 
 @node Testing
 @chapter Testing
 
 The codeless backend can be well tested by the use of various test cases
-that has been implemented for the current scenario. Two test cases have
-been implemented to check the functionality. For the implemtation part a
+that have been implemented for the current scenario. Two test cases have
+been implemented to check the functionality. For the implementation part, a
 selenium script has been written which uses geckodriver to run the script.
-Selenium automates browsers. It create robust tests.
+Selenium automates browsers. It creates robust tests.
 A process to check the registration part as well the login part has been
 written. To run the test follow:
 
@@ -263,16 +263,16 @@ The following image illustrates the various use case of 
codeless payment:
 There are three parties for which codeless payment backend serves
 @itemize
 @item Merchant
-The Merchant has the ability to access the codeless payemnt backend
+The Merchant has the ability to access the codeless payment backend
 by logging in the platform. Codeless is a platform for the merchant
 where they can manage their inventory and simultaneously create a
 'Buy Now' button for the specific product. This code can be directly
 copy pasted on the seller's frontend and can be used for 'Pay with Taler'.
 @item Buyer
 The Buyer will access the seller's frontend where the code
-for 'Buy Now' button is copy pasted. The buysers clicks on the payemnt
+for 'Buy Now' button is copy pasted. The buyers click on the payment
 button to pay with Taler. They enter their shipment details and redirected
-to the payment page. After successfull payment the buyer can track his
+to the payment page. After successful payment, the buyer can track his
 shipment for physical products or view the digital version hosted by the
 codeless payment frontend.
 @item Admin
@@ -283,38 +283,37 @@ perform all the task that a Merchant can perform.
 @node Limitation
 @chapter Limitation
 
-There are certain limitations that exists in thecodeless payment
-baackend. The reset password works only when the backend is running
-locally. Untill and unless, the backend is backend is deployed
-on the server it won't work. Anothere limitation that exist is the
+There are certain limitations that exist in the codeless payment
+backend. The reset password works only when the backend is running
+locally. Until and unless the backend is backend is deployed
+on the server it won't work. Another limitation that exists is the
 email notification when the stocks run below a certain limit. The
 minimum number of products required to be maintained in the stocks
-is currently taken from the seller but no email notification is send.
-
+is currently taken from the seller but no email notification is sent.
 @node Future Work
 @chapter Future Work
 
-The backend of codeless payment is very roboust and can be easily
+The backend of codeless payment is very robust and can be easily
 extended as per the requirements. It is adaptive to add new features
-to this framework. But as per the dicussion and the scope of this
-project there are various features that will be soon added in the
+to this framework. But as per the discussion and the scope of this
+project, there are various features that will be soon added in the
 Codeless Merchant Backend.
 The list of future work is a s follows:
 
 @itemize
 @item
-To send Email notification to the Merchant wwhen the stocks run below a
+To send an Email notification to the Merchant when the stocks run below a
 certain limit. The minimum quantity required to be maintained in
 the stocks is currently taken from the Merchant(specific to each
 product) but no such notification system is designed.
 @item
-To add API access to the merchant backend via the codeless payment 
-service. Basically it would be used as a hosting platform for multiple
+To add API access to the merchant backend via the codeless payment
+service. Basically, it would be used as a hosting platform for multiple
 merchants. There would be an additional user interface part in
 the codeless payment service where a logged-in merchant can generate an
 API key. This API key can be used to access the functionality of the
 merchant backend in a controlled way. After requesting an API key, the
-page would display the generated key and a base URL for the API to used
+page would display the generated key and a base URL for the API to use
 by the seller, which is handled by the codeless payments service.
 @item
 Mapping every seller account to a separate merchant backend instance.
@@ -327,8 +326,8 @@ To add various analytics for the Merchant. Various analysis 
could be
 performed on the orders placed for the respective merchant. Some of
 the analysis that can be performed are displaying the most frequently
 purchased product, some insights about the shipment tracking, analysis
-of products based on delivery location, etc. For this part, dicussions and
-some more research has to be done before procedding to the implementation. 
+of products based on delivery location, etc. For this part, discussions and
+some more research has to be done before proceeding to the implementation.
 @end itemize
 
 @c **********************************************************

-- 
To stop receiving notification emails like this one, please contact
address@hidden