minor edits

1 files changed, 7 insertions, 7 deletions

diff --git a/articles/ui/ui_short.tex b/articles/ui/ui_short.tex
index ab964d60c..f1b37b970 100644
--- a/articles/ui/ui_short.tex
+++ b/articles/ui/ui_short.tex
@@ -91,7 +91,7 @@ system (Figure~\ref{fig:system}).
 In Taler, customers use a {\em wallet} to withdraw, hold, and spend coins.
 Withdrawing coins requires the customer to authenticate and to optionally
 authorize the specific transaction, e.g. via a PIN/TAN method as commonly used
-by banks.  Afterwards, the customer can anonymously spend his coins by visiting
+by banks.  Afterwards, the customer can anonymously spend their coins by visiting
 merchants without having to authenticate for each transaction.
 
 The wallet is implemented as a cross-platform browser extension.  All
@@ -177,7 +177,7 @@ instance of the digital contract with the opportunity to pay for it.
 
 The case where a user already payed for a resource and then visits
 the resource URL (instead of the fulfillment URL) after losing temporary
-session state is also handled correctly, since the wallet component will
+session state is also handled as expected, since the wallet component will
 look for contracts that refer to the same resource.
 
 While Taler is designed to work well with digital resources on the web,
@@ -197,8 +197,8 @@ are being purchased.
 %\end{figure}
 
 
-A new payment system must also be easy to deploy for merchants.
-Figure~\ref{fig:frobearch} shows how the secure payment components of
+A new payment system must also be easy to integrate and deploy for merchants.
+Figure~\ref{fig:frobearch} shows how the security critical payment components of
 Taler interact with the logic of existing Web shops.  First, the Web shop
 front-end is responsible for constructing the shopping cart.  For this,
 the shop front-end generates the usual Web pages which are shown to the
@@ -206,8 +206,8 @@ user's browser client front-end.  Once the order has been constructed,
 the shop front-end gives a {\em proposed contract} in JSON format to
 the payment backend, which signs it and returns it to the front-end.
 The front-end then transfers the signed contract over the network, and
-passes it to the wallet.  Here, the wallet operates from a secure {\em
-background} on the client side, which allows the user to securely
+passes it to the wallet.  Here, the wallet operates from a secure
+background context on the client side, which allows the user to securely
 accept the payment, and to perform the cryptographic operations in a
 context that is protected from the Web shop.  If the user accepts, the
 resulting signed coins are transferred from the client to the server,
@@ -235,7 +235,7 @@ contract to the backend and {\bf (8)} executing fulfillment business
 logic if the backend confirms the validity of the payment.
 
 
-To setup a Taler backend, the merchant only needs to let it know the
+To setup a Taler backend, the merchant only needs to configure it with the
 respective wire transfer routing details, such as an IBAN number.  The
 customer's authentication of the Web shop continues to rely upon
 \mbox{HTTPS}/X.509.