Doc: language review Qt Purchasing

Change-Id: Iab9d13f1abccf0d0b7717360bffbbb60b427a482
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>

src/purchasing/doc/src/googleplay.qdoc

@@ -56,7 +56,7 @@
   \uicontrol{Build Android APK} to see it.
 
   Once the manifest is added to your project, you can modify it. The most
-  important part is the application name and package name. The
+  important parts are the application name and the package name. The
   package name must be unique, and it is recommended to follow the
   com.mycompany.myappname naming convention. The "com.mycompany"
   namespace is based on the Internet domain ownership to avoid naming
@@ -65,7 +65,7 @@
   Other important parts of the manifest include the \c versionCode, which must
   be incremented every time you upload a new version of the application. Other
   properties will decide how your application package
-  is presented in the store listing, such as the application name and version
+  is presented in the store listing, such as the application name and the version
   name.
 
   Finally, the application needs the billing permission. If you disabled
@@ -123,12 +123,12 @@
   \uicontrol{Beta testing} or \uicontrol{Alpha testing} tab, and mark the
   application as \uicontrol{published}.
 
-  When the selected test users you add to your alpha or beta program purchase
-  in-app products in your application, they will make actual purchases and will
-  be charged for them. For testing purchases, you can register the e-mail
+  When the selected test users that you have added to your alpha or beta program
+  purchase in-app products in your application, they will make actual purchases
+  and will be charged for them. For testing purchases, you can register the e-mail
   addresses that should have testing access, under \uicontrol{Settings}
   in the developer console. The users with these e-mail addresses can purchase
-  your in-app products as without being charged for the purchase, and the
+  your in-app products without being charged for the purchase, and the
   transaction is canceled automatically at a later stage.
 
   \section2 Adding In-App Products

src/purchasing/doc/src/qtpurchasing-overview.qdoc

@@ -41,7 +41,7 @@
   content to virtual items. The Qt Purchasing API is built on the system APIs
   for in-app purchases, which means the purchase process is more familiar to
   the user, and the information already stored by the platform (such as credit
-  card information) can be employed to simplify the purchase process.
+  card information) can be used to simplify the purchase process.
 
   \section1 Getting Started
 
@@ -52,9 +52,9 @@
   \section2 The Store
 
   The in-app products must be registered in the target stores, before they
-  could be queried or purchased in an application. Using same identifiers for
-  the products in each of the stores is recommended, as it makes the code to
-  query and purchase the products simpler.
+  can be queried or purchased in an application. We recommend using the same
+  identifiers for the products in each store, as it simplifies the code to
+  query and purchase the products.
 
   \list
   \li \l{Registering Products in Google Play}
@@ -65,9 +65,9 @@
   \section2 Writing the Code
 
   Depending on what fits best with the application, you can choose to use either C++ or
-  QML to support in-app purchasing. If the majority of the user interface is written
-  in QML, it is recommended that you use the QML types, which provide a simple and
-  declarative point of access for the products in the store.
+  QML to support in-app purchasing. If most of the user interface is written in QML,
+  we recommend that you use the QML types, which provide a simple and declarative
+  point of access for the products in the store.
 
   \list
   \li \l{Getting Started with Qt Purchasing in QML}