summaryrefslogtreecommitdiffstats
path: root/src
diff options
context:
space:
mode:
authorLiang Qi <liang.qi@qt.io>2017-04-18 22:04:05 +0200
committerLiang Qi <liang.qi@qt.io>2017-04-18 22:04:05 +0200
commitc8d11ac9a5e814856a47f712d2ee7a6d38700a4c (patch)
tree182d072a27bde430d8b2ccca466c06536d20ed00 /src
parent2721822a8b51d58b40ffc50892fd6e1c480fa09a (diff)
parent1e16d026f1081ce132b999f0704ceeec269f3afd (diff)
Merge remote-tracking branch 'origin/5.8' into 5.9
Diffstat (limited to 'src')
-rw-r--r--src/purchasing/doc/src/googleplay.qdoc12
-rw-r--r--src/purchasing/doc/src/qtpurchasing-overview.qdoc14
2 files changed, 13 insertions, 13 deletions
diff --git a/src/purchasing/doc/src/googleplay.qdoc b/src/purchasing/doc/src/googleplay.qdoc
index d69b5cb..cbdf481 100644
--- a/src/purchasing/doc/src/googleplay.qdoc
+++ b/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
diff --git a/src/purchasing/doc/src/qtpurchasing-overview.qdoc b/src/purchasing/doc/src/qtpurchasing-overview.qdoc
index 322888e..a4a9034 100644
--- a/src/purchasing/doc/src/qtpurchasing-overview.qdoc
+++ b/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}