Changes: Corrected linguistic issues in reference documentation

RevBy: Tomas Junnonen
By: Taru Laine
Details:
Corrected linguistic issues in reference documentation such as:
- Passive changed to active voice
- Imperative used
- Step lists created
- Titles changed for consistency (-ing form preferred)
- Changed AmE to BrE spelling

Additionally, replaced DirectUI with MeeGo Touch.

38 files changed, 1576 insertions, 1875 deletions

diff --git a/doc/src/appletdevelopment.dox b/doc/src/appletdevelopment.dox
index d0491215..8065582c 100644
--- a/doc/src/appletdevelopment.dox
+++ b/doc/src/appletdevelopment.dox
@@ -1,40 +1,40 @@
-/*! \page appletdevelopment Applet development How-To
+/*! \page appletdevelopment Developing applets
 
-An applet is a small program ran in an applet runner process that can be embedded to a Mashup canvas (a.k.a. Experience canvas).
+An applet is a small program which runs in an applet runner process that can be embedded to a mashup canvas (also called Experience canvas).
 
 \section appletterminology Terminology
 
-- \b Applet - is the package installed to the system that contains the binary and resources that offers the functionality of the applet
-- \b Applet \b instance - is a running process of some applet. There can be multiple instances of an applet running simultaneously
+- \b Applet - package installed to the system that contains the binary and resources that provide the functionality of the applet.
+- \b Applet \b instance - running process of an applet. Multiple instances of an applet can run simultaneously.
 - Applet lifecycle:
-  - \b Add - A new applet instance is placed on the applet canvas (i.e. Desktop). Homescreen initiates an instance construction from applet binary. The same operation occurs when already added applet instance is restored after homescreen has been closed and reopened (e.g. when device has been turned off and back on). When applet instance is added for the first time to the canvas the applet instance specific data is empty. When applet instance is restored the applet instance specific data is restored from pre-closed state.
-  - \b Close -An applet instance is closed. This might occur for instance when homescreen is shut down (e.g. when device is turned off). It's good to make a distinction between this and \b remove.
-  - \b Remove - This occurs when an applet instance is removed from applet canvas. All applet instance specific data is removed. Also applet developer should remove any data it has stored for this particular applet instance. This means that applet instance is not added to the applet canvas again when homescreen is restarted the next time.
+  - \b Add - A new applet instance is placed on the applet canvas (in other words, Desktop). The homescreen initiates an instance construction from the applet binary. The same operation occurs when an already added applet instance is restored after the homescreen has been closed and reopened (for example, when a device has been turned off and back on). When an applet instance is added to the canvas for the first time, the applet instance specific data is empty. When an applet instance is restored, the applet instance specific data is restored from the pre-closed state.
+  - \b Close -An applet instance is closed. This might occur, for instance, when the homescreen is shut down (for example, when a device is turned off). Note: This state is different from \b remove.
+  - \b Remove - An applet instance is removed from applet canvas. All applet instance specific data is removed. The applet developer should remove any data stored for this particular applet instance. The applet instance is not added to the applet canvas when the homescreen is restarted.
 
 \section appletdevenv Development environment
 
-For developing applets you need:
-- libdui-dev
+To develop applets, you need:
+- libmeegotouch-dev 
 
 \section appletdevelopment Developing an applet
 
-From a developers point of view an applet consists of a shared library, a metadata file and possibly some resources (such as images). All of these are put into a debian package to enable installation of applets to devices.
+From the developer's point of view, an applet consists of a shared library, a metadata file, and possibly resources (such as images). All the contents are packaged into a Debian package so that the applets can be installed to a device.
 
 \image html appletdevelopment.png "Applet development classes"
 
-\subsection appletclasses What classes to implement
+\subsection appletclasses Classes to implement
 
-From the user interface point of view an applet is a \c MWidget. So construct a \c MWidget class in whatever way fits your purposes: use one of the existing derived classes in libdui, do your own widget or whatever. This is the UI part of your applet.
+From the user interface point of view, an applet is a \c MWidget. Construct a \c MWidget class as you like, for instance, by using one of the existing derived classes in libmeegotouch or by creating your own widget. This is the UI part of your applet.
 
-Whatever approach you chose for constructing your applet \c MWidget, you need to offer a connection point for the host process to get a handle to it. For this you need to implement an interface called \c MAppletInterface. There is only a single method in this interface you need to implement:
+Regardless of the approach chosen for constructing your applet \c MWidget, you need to provide a connection point for the host process. For this, you need to implement an interface called \c MAppletInterface. You only need to implement one method in this interface:
 
 \c MAppletInterface::constructWidget(const MAppletMetaData&, MDataStore&, MDataAccess&)
 
 In this method you need to return a pointer to the \c MWidget of your applet.
 
-\b Note: The ownership of the \c MWidget is transformed to the caller of this method, so \b you \b mustn't \b destroy the widget yourself.
+\b Note: The ownership of the \c MWidget is transformed to the caller of this method, so \b you \b must not \b destroy the widget yourself.
 
-You also need to use a couple of Qt macros to get things working. A complete example follows:
+You also need to use a couple of Qt macros. For example:
 
 \code
 // myapplet.h
@@ -64,11 +64,11 @@ MWidget* MyApplet::constructWidget(const MAppletMetaData &metadata, MDataStore&
 }
 \endcode
 
-\subsection appletmetadata Create applet metadata
+\subsection appletmetadata Creating applet metadata
 
-Applet metadata is defined in \c .desktop files following <a href="http://www.freedesktop.org/wiki/Specifications/desktop-entry-spec">freedesktop.org desktop entry specification</a>. Applet metadata extends \c .desktop entry specification by defining a new type \b X-MeeGoApplet. Applet metadata specification follows desktop entry specification so that required keys (\em Type, \em Name and \em Exec) have to be defined in the applet metadata.
+Applet metadata is defined in \c .desktop files according to <a href="http://www.freedesktop.org/wiki/Specifications/desktop-entry-spec">freedesktop.org desktop entry specification</a>. Applet metadata extends the \c .desktop entry specification by defining a new type \b X-MeeGoApplet. Thus, the required keys (\em Type, \em Name and \em Exec) have to be defined in the applet metadata.
 
-\b Exec key in applet metadata defines the runner binary which is launched in separate process to run the applet binary. This key needs to be defined but can be left empty. If \b Exec key is left empty the applet is ran inside the host process.
+\b Exec key in applet metadata defines the runner binary which is launched in a separate process to run the applet binary. This key needs to be defined but can be left empty. If \b Exec key is left empty, the applet runs inside the host process.
 
 Applet metadata extends the desktop specification with the following new keys. These keys need to be defined under group X-MeeGoApplet.
 
@@ -81,84 +81,86 @@ Applet metadata extends the desktop specification with the following new keys. T
 </tr>
 <tr>
   <td>Applet</td>
-  <td>Defines the applet binary that will be loaded using the runner defined by the Exec key. This binary needs to be located in \c /usr/lib/dui/applets/ - directory.</td>
+  <td>Defines the applet binary that is loaded using the runner defined by the Exec key. This binary needs to be located in \c /usr/lib/meegotouch/applets/ - directory.</td>
   <td>string</td>
   <td>YES</td>
 </tr>
 <tr>
   <td>Identifier</td>
-  <td>Defines an identifier for the applet. The identifier is used for example defining the applet specific style resource locations.</td>
+  <td>Defines an identifier for the applet. The identifier is used, for example, to define the applet-specific style resource locations.</td>
   <td>string (can contain characters [a-zA-Z0-9_-])</td>
   <td>NO</td>
 </tr>
 </table>
 
-Following is an example of applet metadata specification:
+The following example illustrates an applet metadata specification:
 
 \code
 [Desktop Entry]
 Type=X-MeeGoApplet
 Name=ExampleApplet
 Icon=icon-l-music
-Exec=duiappletrunner
+Exec=mappletrunner
 
 [X-MeeGoApplet]
 Applet=libexampleapplet.so
 \endcode
 
-\subsection appletinstallation Install
+\subsection appletinstallation Installing the applet 
 
-The shared library must be installed to \c /usr/lib/dui/applets/.
+To install the applet:
 
-The metadata \c .desktop file must be installed to \c /usr/share/dui/applets/.
+1. Install the shared library to \c /usr/lib/meegotouch/applets/.
+
+2. Install the metadata \c .desktop file to \c /usr/share/meegotouch/applets/.
 
 \subsection appletpackaging Packaging
 
-Each Debian package can only contain one applet. If applets need to be bundled a meta package that depends on individual applet packages must be created.
+Each Debian package can only contain one applet. If applets need to be bundled, create a meta package that depends on individual applet packages.
 
-The applet package must contain the following meta data:
+The applet package must contain the following metadata:
 
 \code
-Maemo-Desktop-File: /usr/share/dui/applets/your-applet-desktop-file.desktop
+Maemo-Desktop-File: /usr/share/meegotouch/applets/your-applet-desktop-file.desktop
 \endcode
 
-To add this to an applet package modify your \c debian/control file so that the section for the binary package of the applet contains
+To add the metadata to an applet package, modify the section for the applet binary package in your \c debian/control file to include the following:
 
 \code
-XB-Maemo-Desktop-File: /usr/share/dui/applets/your-applet-desktop-file.desktop
+XB-Maemo-Desktop-File: /usr/share/meegotouch/applets/your-applet-desktop-file.desktop
 \endcode
 
 \section appletservices Other services offered to applets
 
 \subsection appletinstancedata Applet instance data
 
-The applet system provides the applet instances with an object that can be used to store applet instance specific data to a permanent storage. Instance specific data is something that is not needed anymore when the applet instance is removed. Instance specific data includes any data that the applet needs to restore an instance. The instance data object is an object that implements the \c MDataStore interface.
+The applet system provides the applet instances with an object that can be used to store applet instance specific data in a permanent storage. When the applet instance is removed, the instance-specific data is not needed anymore. Instance-specific data includes the data that the applet needs to restore an instance. The instance data object implements the \c MDataStore interface.
 
-Applets don't create their own objects of the instance data classes but instead they are provided with one that they should use. The instance data object is provided to the applets via the \c MAppletInterface::constructWidget(const MAppletMetaData&, MDataStore&, MDataAccess&) call as the second argument.
+Applets do not create their own objects of the instance data classes. Instead, the applets are provided with the required instance data object through the \c MAppletInterface::constructWidget(const MAppletMetaData&, MDataStore&, MDataAccess&) call as the second argument.
 
-Whenever the state of an applet instance changes in a way that affects on how the applet instance would be restored, the applet should update the data.
+Whenever the state of an applet instance changes in a way that affects the restoration of the applet instance, the applet should update the data. 
 
 \subsection appletsettings Applet settings
 
-Applets can have settings which can be accessed by the user from the settings dialog. There are two different kinds of settings: \b global and \b instance settings. Global settings affect all running instances of a given applet. Instance settings on the other hand only affect the applet instance that they are associated with.
+There can be applet settings that users can access through the settings dialog. There are two kinds of settings: \b global and \b instance settings. Global settings affect all running instances of a given applet. Instance settings, on the other hand, only affect the applet instance that they are associated with.
 
-The settings can be accessed by the applet code through the interface offered via the \c MAppletInterface::constructWidget(const MAppletMetaData&, MDataStore&, MDataAccess&) call as the third argument.
+The settings can be accessed by the applet code through the interface offered by the \c MAppletInterface::constructWidget(const MAppletMetaData&, MDataStore&, MDataAccess&) call as the third argument.
 
-The instance and global settings are both accessed through this same interface. The user of the settings object can't really tell the difference between instance and global settings - they are intermixed.
+The instance and global settings are both accessed through this same interface. The user of the settings object cannot distinguish between instance and global settings - they are intermixed.
 
-\b Important: if there is a setting defined with the same name in both the global and instance settings, the global setting gets shadowed by the instance setting. It's the applet developers responsibility to avoid such situations. So as an applet developer: don't specify any settings in both global and instance settings with the same name.
+\b Important: Do not specify settings in both global and instance settings with the same name. If a setting is defined with the same name in both the global and instance settings, the global setting is shadowed by the instance setting. 
 
-The settings of an applet are defined with a <a href="settingslanguageschema.html">settings language</a>. The global and instance settings are defined in separate files. An applet can have both of the settings files present, either one or neither. It is totally up to the applet's use case what kind of settings it needs to have.
+The settings of an applet are defined with a <a href="settingslanguageschema.html">settings language</a>. The global and instance settings are defined in separate files. An applet can contain one or both settings files, or no settings file at all. The settings depend entirely on the use case of the applet.
 
-The titles of the various settings can be localized, by providing a translation id as the value for the title attribute in the settings xml file. If localization of a title is not required, it can be written as such in the attribute. This requires that the translation catalogs contain only ids with some prefix so they don't conflict with common words.
+The titles of the various settings can be localised by providing a translation ID as the value for the title attribute in the settings XML file. If a title does not need to be localised, it can be written as such in the attribute. The translation catalogs must only contain IDs with a specific prefix so they do not conflict with common words.
 
-A part of the names of the settings files is taken from the applet metadata file basename. For example, if the applet's metadata file is <tt>myapplet.desktop</tt>, it's  basename is \c myapplet. The corresponding file names for the settings files would be \b myapplet-instance.xml and \b myapplet-global.xml for instance and global settings respectively.
+The settings file names are partly taken from the applet metadata file basename. For example, if the applet's metadata file is <tt>myapplet.desktop</tt>, its  basename is \c myapplet. The corresponding settings file names would be \b myapplet-instance.xml for instance settings and \b myapplet-global.xml for global settings.
 
-The installation location for both of these files is the <tt>/usr/share/dui/applets/settings</tt> directory.
+Both files are installed in the <tt>/usr/share/meegotouch/applets/settings</tt> directory.
 
-\subsection appletcontainer Container communication API
+\subsection appletcontainer Using MContainer
 
-Applet may be reparented to a MContainer by MMashupCanvas. MContainer can expose optional applet information on its titlebar, including icon, title and additional informative text.To make an applet reside in a container, set the container-mode property in style sheet of the mashup canvas. An example taken from base style sheet of mashup canvas looks like 
+Applets may be reparented to an MContainer by MMashupCanvas. MContainer can include optional applet information on its title bar, such as the icon, title and additional informative text. To place an applet in a container, set the container-mode property in the style sheet of the mashup canvas. The following example illustrates the base style sheet of the mashup canvas:
 
 \code
 MMashupCanvasStyle {
@@ -166,11 +168,11 @@ MMashupCanvasStyle {
 }
 \endcode
 
-As shown above, default settings for container-mode property is true. When the container-mode property is true(default), an applet is embedded as shown \image html containermodeon.png "Container mode on(default)" 
+As shown above, default settings for container-mode property are true. When the container-mode property is true(default), an applet is embedded, see \image html containermodeon.png "Container mode on(default)" 
 
-When container-mode property to false applet looks like: \image html containermodeoff.png "Container mode off" 
+The following figure illustrates an applet when container-mode property is false: \image html containermodeoff.png "Container mode off" 
 
-Use following properties and signals in your applet widget class to communicate applet information:
+Use the following properties and signals in your applet widget class to provide applet information:
 
 \code
 Q_PROPERTY(QString appletIcon READ icon WRITE setIcon)
@@ -192,81 +194,83 @@ The property and signal names must be as stated above. The property access funct
 
 \subsection appletidentifier Applet identifier
 
-Every applet has an applet identifier that is used in a few places in the applet system. The applet identifier is a string that uniquely identifies the applet. Note however that the applet identifier is not an applet instance specific identifier.
+Every applet has an applet identifier that is used in several places in the applet system. The applet identifier is a string that uniquely identifies the applet. Note: The applet identifier is not specific to an applet instance.
 
 The applet identifier is determined like this:
-- If an identifier (<tt>Identifier</tt>) is specified in the \ref appletmetadata "applet metadata" (and it is valid), that is used
-  - If the identifier in the metadata is not specified or it can't be used (e.g. it is ill-formed) an identifier is extracted from the applet shared library name:
-    - Assuming your applet is packaged to a shared library called <tt>lib<strong>exampleapplet</strong>.so</tt>, the identifier will be <strong>exampleapplet</strong>.
+- If an identifier (<tt>Identifier</tt>) is specified in the \ref appletmetadata "applet metadata" (and it is valid), the identifier is used.
+  - If the identifier in the metadata is not specified or it cannot be used (for example, if it is ill-formed), an identifier is extracted from the applet shared library name:
+    - For example, if your applet is packaged to a shared library called <tt>lib<strong>exampleapplet</strong>.so</tt>, the identifier is <strong>exampleapplet</strong>.
 
 \subsection appletstyling Applet styling
 
-Applets can define their own styles just like any other applications in the MeeGo Touch world. Styling is done with style sheets and images in the \ref styling "usual way". The only important thing with applets is the location of the style resources.
+Applets can define their own styles just like any other applications in the MeeGo Touch world. You can use style sheets and images for \ref styling "in the usual way". In applet styling, the location of the style resources is important.
 
-The \ref appletidentifier "applet identifier" is used in the construction of the resource location. The applet identifier is used as the application name in the directory name. See \ref theme_structure for more information about the directory locations.
+The \ref appletidentifier "applet identifier" is used in the construction of the resource location. The applet identifier is used as the application name in the directory name. For more information on the directory locations, see \ref theme_structure. 
 
 \subsection appletinternationalisation Applet internationalisation
 
-For the most part all \ref i18n "internationalisation guidelines" apply to applets as well. The only thing to notice is that the \ref appletidentifier "applet identifier" is used as the translation catalog name.
+For the most part, all \ref i18n "internationalisation guidelines" apply to applets as well. However, the \ref appletidentifier "applet identifier" is used as the translation catalog name.
 
 \section applettools Tools to help development
 
-The <tt>dui-dev-tools</tt> package includes a tool called <tt>duiapplettester</tt>. This tool can be used to test applets. The tool loads an applet to a window where it can be tested by interacting with it and visually checking the results. It's also easy to run the applet in a debugger tool with this tool.
+The <tt>meegotouch-dev-tools</tt> package includes a tool called <tt>mapplettester</tt> which can be used to test applets. The tool loads an applet to a window where you can interact with it and visually check the results. You can also use this tool for debugging the applet.
 
-You can load an applet with duiapplettester by commanding:
+To load an applet with mapplettester, use the following command:
 
 \code
-duiapplettester <metadatafile>
+mapplettester <metadatafile>
 \endcode
 
 where &lt;metadatafile&gt; is the metadata file name of the applet.
 
-\b Note that the applet must be installed to the system before \em duiapplettester can use it.
+\b Note: The applet must be installed to the system before \em mapplettester can use it.
 
-The \em duiapplettester also supports applet settings. The settings can be accessed by opening the context menu for the applet (right mouse button clicking the applet on an environment that has a mouse).
+The \em mapplettester also supports applet settings. The settings can be accessed by opening the 
+context menu for the applet (for instance, by right-clicking the applet).
 
-\section appletenablers Applet enablers
+\section appletenablers Enabling applets
 
-You don't necessarily need to write your own applet from scratch. You can use one of the general purpose "enabling applets" such as the WWF (Web Widget Framework) or Python applet.
+You do not necessarily need to write your own applet from the very beginning. You can use one of the 
+general-purpose enabling applets such as the WWF (Web Widget Framework) or Python applet.
 
 \section appletpreconfiguring Preconfiguring applets on a mashup canvas
 
-The following information is only meant for application developers who want to preconfigure
-which applets will appear on the mashup canvas by default. Applet developers do not need this
+The following section is only meant for application developers who want to preconfigure
+which applets appear on the mashup canvas by default. Applet developers do not need this
 information.
 
 Each mashup canvas stores information about the applets instantiated on that particular canvas
 in the ~user/.config/appname/canvasname.data file. If this file does not exist when the mashup
-canvas is instantiated the global defaults are copied from /etc/xdg/appname/canvasname.data if
+canvas is instantiated, the global defaults are copied from /etc/xdg/appname/canvasname.data if
 that file exists. This file should be supplied by the application developer if there is a need
 to define which applets should be instantiated on a particular canvas by default.
 
-An example data file follows:
+The following example illustrates the data file:
 
 \code
 [1]
-desktopFile=/usr/share/dui/applets/myapplet.desktop
+desktopFile=/usr/share/meegotouch/applets/myapplet.desktop
 private\layoutIndex=0
 
 [2]
-desktopFile=/usr/share/dui/applets/someotherapplet.desktop
+desktopFile=/usr/share/meegotouch/applets/someotherapplet.desktop
 private\layoutIndex=1
 \endcode
 
 The value in brackets is a canvas specific applet identifier, which is an unsigned integer
 starting from 1. The value of the desktopFile key defines the .desktop file which contains
-the information for this particular applets. The private\\layoutIndex key contains the
+the information for this particular applet. The private\\layoutIndex key contains the
 applet's location in the layout (which is currently just an index - this will change in the
 future).
   
-To be able to define different configurations for different purposes the application package
-should not contain this file. Instead, there should be a settings template package for the
-application which can be instantiated for different configurations. For an example how to
-achieve this refer to the duihomescreen-settings-template package. It contains example
-ConfML, XSLT and GCFML files for the MeeGo Touch Home Screen package in the conf directory, the
-necessary debian packaging files in the debian directory and tests in the tests directory.
-An instantiated version of the template, duihomescreen-settings-default, which also contains
-the sources, can be fetched with apt-get source duihomescreen-settings-default.
+If the application package contains this file, it is not possible to define different configurations for 
+different purposes. Instead, there should be a settings template package for the application which 
+can be instantiated for different configurations. For an example, see the 
+mhomescreen-settings-template package. It contains example ConfML, XSLT and GCFML files for the 
+MeeGo Touch Home Screen package in the conf directory, the necessary debian packaging files in the 
+debian directory and tests in the tests directory. An instantiated version of the template, 
+mhomescreen-settings-default, which also contains the sources, can be fetched with apt-get source 
+mhomescreen-settings-default.
 
 \see
 
diff --git a/doc/src/appletinstallationsource.dox b/doc/src/appletinstallationsource.dox
index 71e25a38..bacfab9c 100644
--- a/doc/src/appletinstallationsource.dox
+++ b/doc/src/appletinstallationsource.dox
@@ -1,70 +1,70 @@
-/*! \page appletinstallationsource Applet installation source development How-To
+/*! \page appletinstallationsource Developing applet installation sources
 
-Applet installation sources are specific type of application extensions that can add plugins to applet library for applet installation. Application extensions are defined in detail in \ref applicationextensions page.
+Applet installation sources are specific application extensions that can add plug-ins to an applet library for applet installation. For more information on application extensions, see \ref applicationextensions.
 
 \section appsourcedevenv Development environment
 
-For developing applet installation sources you need:
-- libdui-dev
+To develop applet installation sources, you need:
+- libmeegotouch-dev
 
 \section appsourcedevelopment Developing applet installation sources
 
-An applet installation source is implemented as a Qt plugin. The interface class used as the base class of all applet installation sources is DuiAppletInstallationSourceInterface which in turn inherits from base class DuiApplicationExtensionInterface. DuiAppletInstallationSourceInterface inherits the following methods from DuiApplicationExtensionInterface and must be implemented by the source:
+An applet installation source is implemented as a Qt plug-in. The interface class used as the base class of all applet installation sources is MAppletInstallationSourceInterface. This class inherits from the base class MApplicationExtensionInterface. MAppletInstallationSourceInterface inherits the following methods from MApplicationExtensionInterface and must be implemented by the source:
 
-\code bool DuiApplicationExtensionInterface::initialize(const QString &interface)
- DuiWidget *widget() \endcode
+\code bool MApplicationExtensionInterface::initialize(const QString &interface)
+ MWidget *widget() \endcode
 These methods are described in \ref appextensiondevelopment section.
 
-DuiAppletInstallationSourceInterface also contains a method which provides the source means to access the applet inventory interface. The following method must be implemented by the source:
+DuiAppletInstallationSourceInterface also contains a method which enables the source to access the applet inventory interface. The following method must be implemented by the source:
 
-\code void setDuiAppletInventoryInterface(DuiAppletInventoryInterface &installationSource) \endcode
-As a parameter it takes a reference to the DuiAppletInventoryInterface. Applet installation sources can use this interface for instantiating applets from an installation source package using the method:
+\code void setMAppletInventoryInterface(MAppletInventoryInterface &installationSource) \endcode
+As a parameter it takes a reference to the MAppletInventoryInterface. Applet installation sources can use this interface for instantiating applets from an installation source package using the method:
 \code void instantiateAppletsInPackage(const QString &packageName) \endcode
 It takes the applet package name to be instantiated as a parameter.
 
-Applet installation source developers need to implement DuiAppletInstallationSourceInterface interface in a plugin library and export their implementation from the library. The applet inventory will create an instance of application extension area and instantiate the available installation sources when needed.
+Applet installation source developers need to implement DuiAppletInstallationSourceInterface interface in a plug-in library and export their implementation from the library. The applet inventory creates an instance of application extension area and instantiates the available installation sources when needed.
 
-\subsection appsourceexample Example of demo applet installation source
+\subsection appsourceexample Example of demo applet installation source:
 
 \code
 // demoappletsource.h
 #ifndef DEMOAPPLETSOURCE_H
 #define DEMOAPPLETSOURCE_H
 
-#include <duiappletinstallationsourceinterface.h>
+#include <mappletinstallationsourceinterface.h>
 
-class DemoAppletInstallationSource : public QObject, public DuiAppletInstallationSourceInterface
+class DemoAppletInstallationSource : public QObject, public MAppletInstallationSourceInterface
 {
     Q_OBJECT
-    Q_INTERFACES(DuiAppletInstallationSourceInterface DuiApplicationExtensionInterface)
+    Q_INTERFACES(MAppletInstallationSourceInterface MApplicationExtensionInterface)
 
 public:
     DemoAppletInstallationSource();
     virtual ~DemoAppletInstallationSource();
-    // methods derived from DuiAppletInstallationSourceInterface
+    // methods derived from MAppletInstallationSourceInterface
     virtual bool initialize(const QString &);
-    virtual DuiWidget *widget();
-    virtual void setDuiAppletInventoryInterface(DuiAppletInventoryInterface &installationSource);
+    virtual MWidget *widget();
+    virtual void setMAppletInventoryInterface(MAppletInventoryInterface &installationSource);
 
     //! Helper method for accessing applet inventory interface
-    DuiAppletInventoryInterface *appletInventoryInterface() const;
+    MAppletInventoryInterface *appletInventoryInterface() const;
 
 private:
-    DuiAppletInventoryInterface *appletInventory;
-    DuiWidget *sourceWidget;
+    MAppletInventoryInterface *appletInventory;
+    MWidget *sourceWidget;
 };
 
 #endif
 
 \endcode
 
-\b Note that the Q_INTERFACES list must include both DuiAppletInstallationSourceInterface and its base interface DuiApplicationExtensionInterface.
+\b Note: The Q_INTERFACES list must include both MAppletInstallationSourceInterface and its base interface MApplicationExtensionInterface.
 
 \code
 
 // demoappletsource.cpp
 #include "demoappletsource.h"
-#include <DuiLibrary>
+#include <MLibrary>
 
 DemoAppletInstallationSource::DemoAppletInstallationSource() : appletInventory(NULL)
 {
@@ -75,23 +75,23 @@ DemoAppletInstallationSource::~DemoAppletInstallationSource()
     delete sourceWidget;
 }
 
-DuiWidget *DemoAppletInstallationSource::widget()
+MWidget *DemoAppletInstallationSource::widget()
 {
     return sourceWidget;
 }
 
 bool DemoAppletInstallationSource::initialize(const QString &)
 {
-    sourceWidget = new DuiWidget;
+    sourceWidget = new MWidget;
     return true;
 }
 
-void DemoAppletInstallationSource::setDuiAppletInventoryInterface(DuiAppletInventoryInterface &installationSource)
+void DemoAppletInstallationSource::setMAppletInventoryInterface(MAppletInventoryInterface &installationSource)
 {
     appletInventory = &installationSource;
 }
 
-DuiAppletInventoryInterface *DemoAppletInstallationSource::appletInventoryInterface() const
+MAppletInventoryInterface *DemoAppletInstallationSource::appletInventoryInterface() const
 {
     return appletInventory;
 }
@@ -100,17 +100,17 @@ DuiAppletInventoryInterface *DemoAppletInstallationSource::appletInventoryInterf
 
 \subsection appsourcedesktopfile Applet installation source desktop file
 
-Following is an example of applet installation source desktop file:
+The following example illustrates an applet installation source desktop file:
 
 \code
 
 [Desktop Entry]
-Type=DUIApplicationExtension
+Type=MApplicationExtension
 Name=DemoAppletInstallationSource
 
 [X-DUI]
-DUIApplicationExtension-Interface=com.nokia.dui.core.AppletInstallationSourceInterface/1.0
-DUIApplicationExtension-Extension=libappletinventory-demoinstallationsource.so
+MApplicationExtension-Interface=com.nokia.dui.core.AppletInstallationSourceInterface/1.0
+MApplicationExtension-Extension=libappletinventory-demoinstallationsource.so
 
 \endcode
 
diff --git a/doc/src/applicationextensions.dox b/doc/src/applicationextensions.dox
index e75ef848..e98da9c4 100644
--- a/doc/src/applicationextensions.dox
+++ b/doc/src/applicationextensions.dox
@@ -1,57 +1,56 @@
-/*! \page applicationextensions Application extension development How-To
+/*! \page applicationextensions Developing application extensions
 
-Application extensions are plugins that can be embedded into an application extension area. They can be run either in the same process as the application or a separate process in the application extension runner. An application extension can optionally have an UI.
+Application extensions are plug-ins that can be embedded into an application extension area. They can be run either in the same process as the application or a separate process in the application extension runner. An application extension can optionally have a UI.
 
 \section appextensiondevenv Development environment
 
-For developing application extensions you need:
+To develop application extensions, you need:
 - libmeegotouch-dev
 
 \section appextensiondevelopment Developing application extensions and applications that use them
 
-From a developers point of view an application extension consists of a shared library, a desktop entry file and possibly some resources (such as images).
-All of these are put into a debian package to enable installation of application extensions to devices.
+From the developer's point of view, an application extension consists of a shared library, a desktop entry file, and possibly resources (such as images).
+All the contents are packaged into a Debian package so that the application extensions can be installed to devices.
 
-An application extension is implemented as a Qt plugin. It is a good practice to name the shared library so that the related application is mentioned in the name in addition to the extension name (for example libmyapplication-myextension.so). The interface class used as the base class of all application extensions is \c MApplicationExtensionInterface.
-The interface provides a method for initializing the plugin, which must be implemented by the application extension:
+An application extension is implemented as a Qt plug-in. It is recommended that the shared library name should include the related application and the extension name (for example, libmyapplication-myextension.so). The interface class used as the base class of all application extensions is \c MApplicationExtensionInterface.
+The interface provides a method for initialising the plug-in, which must be implemented by the application extension:
 \code bool MApplicationExtensionInterface::initialize(const QString &interface) \endcode
-The extension gets the name of the interface as a parameter. The extension can but does not need to use this information for any purpose.
-The boolean return value should indicate whether the initialization was successful or not.
+The extension gets the name of the interface as a parameter. The extension can use this information, but does not need it for any purpose.
+The boolean return value should indicate whether the initialisation was successful or not.
 
-The interface also has an method for returning the widget used for the UI of the application extension:
+The interface also has a method for returning the widget used for the UI of the application extension:
 \code QGraphicsWidget *widget() \endcode
-In this method you need to return a pointer to the \c QGraphicsWidget of your application extension. In case an UI is not required, this method can be left out.
+In this method you need to return a pointer to the \c QGraphicsWidget of your application extension. In case a UI is not required, this method can be left out.
 \b Note: The ownership of the \c QGraphicsWidget is left to the application extension, so you should destroy the widget yourself in the destructor of the extension.
 
-To use application extensions of particular interface in an application, an instance of \c MApplicationExtensionArea is created:
+To use application extensions of a particular interface in an application, an instance of \c MApplicationExtensionArea is created:
 
 \code
 new MApplicationExtensionArea(interface, parent);
 \endcode
 
-where interface is the name of the interface the extensions in the area implement and parent is the parent QGraphicsItem. The area will only
-be populated after init() is called.
+where interface refers to the interface implemented by the extensions in the area and parent is the parent QGraphicsItem. The area is only
+populated after init() is called.
 
-It is possible to define which extensions are allowed to be loaded in the same process as the extension area and which extensions are ran in separate
-processes using setInProcessFilter() and setOutOfProcessFilter() before calling init(). These take QRegExp objects as their parameter, so it is for
-example possible to use QRegExp("$^") to allow no extensions, QRegExp("/test(1|A).desktop$") to allow extensions test1.desktop and testA.desktop and
+To define which extensions can be loaded in the same process as the extension area and which extensions run in separate
+processes, use setInProcessFilter() and setOutOfProcessFilter() before calling init(). Since these methods take QRegExp objects as their parameter, you can, for example, use QRegExp("$^") to allow no extensions, QRegExp("/test(1|A).desktop$") to allow extensions test1.desktop and testA.desktop and
 QRegExp() to allow all extensions.
 
 \subsection appextensionprocdiff Differences between in-process and out-of-process application extensions
 
-Developing application extensions and the application that uses them is done differently depending whether the extensions can be run in-process or out-of-process.
+Application extensions and applications that use them are developed differently depending on whether they are run in-process or out-of-process.
 
-In-process
+In-process extensions:
 - direct communication between application and extension supported by subclassing MApplicationExtensionInterface
 - the extension can open dialogs and views
 - the extension can extend the applications UI
 - the extension can crash the host application
 
-Out-of-process
+Out-of-process extensions:
 - direct communication between application and extension not supported
-- the extension can not open dialogs or views
-- the extension can not draw outside the extensions area
-- the extension can not crash the host application
+- the extension cannot open dialogs or views
+- the extension cannot draw outside the extensions area
+- the extension cannot crash the host application
 
 \subsection appextensionexample Example of an in-process extension
 \code
@@ -106,7 +105,7 @@ private:
 #endif
 \endcode
 
-\b Note that the Q_INTERFACES list must include both the demo specific interface DemoExtensionInterface and the base interface MApplicationExtensionInterface.
+\b Note: The Q_INTERFACES list must include both the demo-specific interface DemoExtensionInterface and the base interface MApplicationExtensionInterface.
 
 \code
  // demoextension.cpp
@@ -145,8 +144,8 @@ MWidget *DemoApplicationExtension::widget()
 
 \endcode
 
-In the application that wants to use the extensions implementing the com.meego.DemoExtensionInterface/1.0 defined above,
-the application should create an application extension area like this:
+In an application that wants to use the extensions implementing the com.meego.DemoExtensionInterface/1.0 defined above,
+the application should create the following application extension area:
 
 \code
 #include <MApplicationExtensionArea>
@@ -182,11 +181,11 @@ void DemoApp::addExtension(MApplicationExtensionInterface *extension)
 \subsection appextensiondesktopfile Application extension desktop file
 
 Application extension must have a \c .desktop file written according to <a href="http://www.freedesktop.org/wiki/Specifications/desktop-entry-spec">freedesktop.org desktop entry specification</a>.
-It is a good practice to name the file in a similar manner to naming the shared library (for example myapplication-myextension.desktop).
+It is recommended to name the file in a similar manner as the shared library (for example, myapplication-myextension.desktop).
 The keys \c Type and \c Name are required as specified in the desktop entry specification. The type must be \c X-MeeGoApplicationExtension.
-The \c Exec key is optionally used to specify a runner binary (usually mapplicationextensionrunner) which is launched in separate process to run the application extension binary. If the key is not used, the application extension is run inside the host process.
+The \c Exec key is optionally used to specify a runner binary (usually mapplicationextensionrunner) which is launched in a separate process to run the application extension binary. If the key is not used, the application extension runs inside the host process.
 
-Application extensions extend the specification by defining a new type \b MApplicationExtension and the following new keys that are put inside the X-MeeGoApplicationExtension group:
+Application extensions extend the specification by defining a new type \b MApplicationExtension and the following new keys which are placed into the X-MeeGoApplicationExtension group:
 
 <table>
 <tr>
@@ -210,13 +209,13 @@ Application extensions extend the specification by defining a new type \b MAppli
 <tr>
   <td>Identifier</td>
   <td>Defines an identifier for the application extension.
-  The identifier is used for example defining the application extension specific style resource locations when it's run as out-of-process.</td>
+  The identifier is used, for example, for defining the application extension specific style resource locations when the extension is run out-of-process.</td>
   <td>string (can contain characters [a-zA-Z0-9_-])</td>
   <td>NO</td>
 </tr>
 </table>
 
-Following is an example of application extension desktop file:
+The following example illustrates an application extension desktop file:
 
 \code
 [Desktop Entry]
@@ -229,11 +228,11 @@ Interface=com.meego.DemoExtensionInterface/1.0
 Extension=libdemoapplication-demoextension.so
 \endcode
 
-\subsection appextensioncontainer Container communication API
+\subsection appextensioncontainer Using MContainer
 
-Application extension widgets are by default reparented to a MContainer.
-MContainer can expose optional application extension information on its titlebar, including icon, title and additional informative text.
-To make an application extension not reside in a container, set the container-mode property of the application extension area to false:
+Application extension widgets are reparented to an MContainer by default.
+MContainer can include optional application extension information on its title bar, such as icon, title and additional informative text.
+If you do not want an application extension to reside in a container, set the container-mode property of the application extension area to false:
 
 \code
 MApplicationExtensionAreaStyle {
@@ -241,7 +240,7 @@ MApplicationExtensionAreaStyle {
 }
 \endcode
 
-Use following properties and signals in your application extension widget class to communicate container information:
+Use following properties and signals in your application extension widget class to provide container information:
 
 \code
 Q_PROPERTY(QString applicationExtensionIcon  READ icon  WRITE setIcon)
@@ -268,22 +267,22 @@ Every application extension has an application extension identifier string that
 The application extension identifier is determined like this:
 - if an identifier (<tt>Identifier</tt>) is specified in the <tt>X-MeeGoApplicationExtension</tt> group of the \ref appextensiondesktopfile desktop file (and it is valid), that is used
 - otherwise, an identifier is extracted from the application extension shared library name:
-  assuming your application extension is packaged to a shared library called <tt>lib<strong>exampleapplicationextension</strong>.so</tt>, the identifier will be <strong>exampleapplicationextension</strong>.
+  For example, if your application extension is packaged to a shared library called <tt>lib<strong>exampleapplicationextension</strong>.so</tt>, the identifier is <strong>exampleapplicationextension</strong>.
 
 \subsection appextensionstyling Application extension styling
 
 Application extensions can define their own styles just like any other application in the MeeGo Touch world.
+
 Styling is done with style sheets and images in the \ref styling "usual way".
 The only important thing with application extensions is the location of the style resources.
 
-The \ref appextensionidentifier "application extension identifier" is used in the construction of the resource location when the application extension is run as out-of-process.
-The application extension identifier is used as the application name in the directory name.
+When the application extension is run out-of-process, the resource location is constructed from the \ref appextensionidentifier "application extension identifier". The application extension identifier is used as the application name in the directory name.
 
-When the application extension is run as in-process, the resource location is constructed from the library name.
+When the application extension is run in-process, the resource location is constructed from the library name.
 
-See \ref theme_structure for more information about the directory locations.
+For more information about the directory locations, see \ref theme_structure.
 
-The layout orientation of the application extension area can be modified using the layout-orientation style parameter:
+You can modify the layout orientation of the application extension area with the layout-orientation style parameter:
  
 \code
 MApplicationExtensionAreaStyle {
@@ -293,16 +292,16 @@ MApplicationExtensionAreaStyle {
 
 \section appextensiontools Tools to help development
 The <tt>meegotouch-dev-tools</tt> package includes a tool called <tt>mapplicationextensiontester</tt>. This tool can be used to test application extensions that have an UI.
-The tool loads application extensions implementing a specified interface to a window where they can be tested by interacting with them and visually checking the results.
-It's also easy to run the extension in a debugger with this tool.
+The tool loads application extensions implementing a specified interface to a window where you can interact with it and visually check the results. 
+It is also easy to run the extension in a debugger with this tool.
 
-You can load an application extension with the tool by giving the command:
+To load an application extension with the tool, use the following command:
 
 \code
 mapplicationextensiontester <interfacename>
 \endcode
 
-where &lt;interfacename&gt; is the interface the extensions to be loaded must implement.
+where &lt;interfacename&gt; is the interface that the loaded extensions must implement.
 
 \b Note that the application extensions must be installed to the system before \c mapplicationextensiontester can use them.
 
diff --git a/doc/src/bugreporting.dox b/doc/src/bugreporting.dox
index aa3d5e95..34ce4bad 100644
--- a/doc/src/bugreporting.dox
+++ b/doc/src/bugreporting.dox
@@ -1,9 +1,9 @@
-/*! \page bugreporting How to Report a Bug
+/*! \page bugreporting Reporting a bug
 
-Bugs can be entered in the <a href="http://bugs.meego.com/enter_bug.cgi?product=MeeGo%20Touch%20Framework">MeeGo Bugzilla</a>.
+You can add bugs to the <a href="http://bugs.meego.com/enter_bug.cgi?product=MeeGo%20Touch%20Framework">MeeGo Bugzilla</a>.
 
-Please check Bugzilla for existing bugs that might cover your problem before filing a new one.
+Before reporting a new bug, check that it does not already exist in Bugzilla.
 
-If possible, try to include a small test case or program that demonstrates the problem.
+It is recommended that you include a minor test case or program that demonstrates the problem.
 
 */
diff --git a/doc/src/commoncomponents.dox b/doc/src/commoncomponents.dox
index 545ab4d5..b2041672 100644
--- a/doc/src/commoncomponents.dox
+++ b/doc/src/commoncomponents.dox
@@ -1,33 +1,31 @@
-/*! \page commoncomponents Common Components
+/*! \page commoncomponents Common components
 
-\section components Components
+\section components Introduction
 
 \em A "common component" is a reusable element of the MeeGo Handset user interface. Typical components include
 the standard UI controls such as buttons, sliders, and lists, as well as the more complex dialogs and menus.
 
-Components are also \a widgets (specifically QGraphicsWidgets) and can be used anywhere a widget can, but
-common components also have some unique features that means not every widget is a component:
+Components are also \a widgets (specifically QGraphicsWidgets) and can be used wherever widgets can be used. However, all widgets cannot be regarded as components due to some unique features that common components have.
 
-\section componentfeatures Common component features
+\section componentfeatures Features of common components
+
+Common components have the following features:
 
 - Components provide a consistent experience that fits the MeeGo Handset design
 - All components are designed for finger use
-- Components scale to physical sizes (i.e. millimeters instead of pixels), regardless of the device resolution or pixel density
+- Components scale to physical sizes (in other words, millimeters instead of pixels), regardless of the device resolution or pixel density
 - Components are fully stylable through CSS
-- The entire look and feel implementation of a component is exchangable through theming while keeping the existing API
-- Components may have alternative versions (look and feel) for different uses
+- You can change the entire look-and-feel implementation of a component through theming while keeping the existing API
+- Components may have alternative versions (look-and-feel) for different purposes
 - Components always work in both landscape and portrait orientations
-- Components are performance and power consumption optimized
+- Performance and power consumption of components is optimised
 
-While applications are seldom created out of only common components, by using the common components where
-applicable instead of creating custom controls, your application will fit in with the rest of the MeeGo
-user experience. This will also help your users transfer what they have learned from other MeeGo applications
-to yours.
+While applications are not usually created of only common components, use common components instead of custom controls where applicable to ensure that your application fits in with the rest of the MeeGo user experience. This also helps your users to transfer what they have learned from other MeeGo applications to your application.
 
-\note For general MeeGo usage patterns and UI recommendations, please see:
+\note For information on general MeeGo usage patterns and UI recommendations, see:
 - <a href="http://meego.com/developers/ui-design-guidelines/handset/designing-your-application">Designing your Application</a>
 
-\section componentdetails The components
+\section componentdetails Common component types
 
 \subsection button Button
 Class: MButton
@@ -39,140 +37,131 @@ The following button types are available:
 
 \image html button.png Button
 - \b Push
-Use the push button to execute an action. The push button maintains no memory and typically exectues the same
-action each time when presssed.
+Executes an action. Push button maintains no memory and typically executes the same action each time when pressed.
 
 \image html iconbutton.png "Icon button"
 - \b Icon
-Icon buttons function like the push button, but are visually distinctive with an icon taking the usual
-place of the descriptive text. They are typically used in toolbars and other places where space is limited.
+Has the same functionality as the Push button but a different appearance, since it usually replaces descriptive text. Icon button is typically used in tool bars and other places where space is limited.
 
-\image html checkbox.png Checkbox
-- \b Checkbox
-A check box permits the user to make multiple selections from a number of options. A caption describing the meaning of the check box is shown adjacent to the check box. Inverting the state of a check box is done by tapping the box.
+\image html checkbox.png Check box
+- \b Check box
+Allows the user to make multiple selections from several options. There is a descriptive caption next to the check box. You can change the state of the check box by tapping the box.
 
 \image html switch.png Switch
 - \b Switch
-Use switches for functions that the user can set on and off.
+Allows the user to set functions on and off.
 
 \subsection list List
 Class: MList
 
 \image html list.png List
 
-A list is a container of objects displayed vertically. The list should be used when the number of items is very
-large or dynamic, otherwise consider using a <a href="layouts.html">layout</a> instead.
+Displays objects vertically. Use a list when there are numerous items or the items are subject to change. Otherwise consider using a <a href="layouts.html">layout</a> instead.
 
-The list can contain any type of QGraphicsWidget, but typically a MListItem is used.
+A list can contain any type of QGraphicsWidget, but typically a MListItem is used.
 
 \subsection textedit Text edit
 Class: MTextEdit
 
-A text edit is used for user input of text. The edit can be a single or multiple lines, or it can expand as
+Allows the user to input text. The edit include a single line or multiple lines, or it can expand if
 necessary. When a hardware keyboard is not available, the text edit interacts with the virtual on-screen input methods.
 
 \subsection label Label
 Class: MLabel
 
-A label displays a piece of text in the UI. The MeeGo Touch label supports both markup and links in labels.
+Displays text in the UI. The MeeGo Touch label supports both markup and links.
 
 \subsection image Image
 Class: MImageWidget
 
-The image represents a single picture in the UI.
+Represents a single picture in the UI.
 
 \subsection videowidget Video
 Class: MVideoWidget
 
-The video widget supports flexible playback of video in the UI. The widget can for example be rotated along with the
+Supports flexible playback of video in the UI. The widget can, for example, be rotated along with the
 rest of the UI and have transparent controls overlaid.
 
 \subsection applicationpage Application page
 Class: MApplicationPage
 
-The application page is one view of an application, navigation inside the application typically happens by
-switching between multiple pages.
+Provides one view of an application. You can typically navigate inside the application by switching between multiple pages.
 
 \subsection applicationmenu Application menu
 Class: MApplicationMenu
 
 \image html applicationmenu.png "Application menu"
 
-The application menu is typically not directly accessed, instead actions are added to an MApplicationPage. This allows
+Is typically not directly accessible. Instead, actions are added to an MApplicationPage. This allows
 the menu to be reconfigured automatically as the user switches between pages in the application.
 
-The application menu consists of a list of commands related to the current application view, or application wide commands.
+The application menu consists of a list of commands related to the current application view or the entire application.
 
 \subsection dialog Dialog
 Class: MDialog
 
 \image html dialog.png Dialog
 
-Use dialogs when you want a response from the user while blocking access to the rest of the application.
-Unlike notifications, dialogs do not disappear from the UI without user interaction.
+Requires a response from the user and blocks access to the rest of the application. Unlike notifications, dialogs do not disappear from the UI without user interaction.
 
 \subsection objectmenu Object menu
 
 \image html objectmenu.png "Object menu"
 
-An object menu is a list of contextual actions that can be performed on a certain object. The object menu
+Lists contextual actions that can be performed on a certain object. The object menu
 is automatically constructed by the MeeGo Touch framework when the <a href="gestures.html">tap and hold gesture</a>
-is used on a widget. The contents of the menu are the QActions and MActions added to the widget.
+is used on a widget. The menu consists of the QActions and MActions added to the widget.
 
 \subsection toolbar Tool bar / Tab bar
 
-\image html toolbar.png "Toolbar in landscape"
-\image html toolbar-portrait.png "Toolbar in portrait"
+\image html toolbar.png "Tool bar in landscape"
+\image html toolbar-portrait.png "Tool bar in portrait"
 
-The toolbar holds a list of the most important actions relevant to the current application page/view. The
-toolbar is reconfigured automatically based on the actions added to the currently active page.
+Tool bar lists the most important actions for the current application page/view. The tool bar is reconfigured automatically when actions are added to the currently active page.
 
-The tab bar is an alternative way of providing navigation inside an application, where the most commonly
-used UI views are directly accessible from where the toolbar would normally reside.
+Tab bar is an alternative way of providing navigation inside an application. A tab bar provides direct access to the most commonly used UI views.
 
 \subsection slider Slider
 Class: MSlider
 
 \image html slider.png Slider
 
-Use a slider for a selecting a value from a range.
+Allows the user to select from a range of values.
 
 \subsection seekbar Seekbar
 Class: MSeekbar
 
-\image html seekbar.png Seekbar
+\image html seekbar.png Seek bar
 
-The seekbar is a specialization of the slider. Unlike the slider, it supports visualizing the amount
-of currently loaded content in the set value range.
+Displays the amount of currently loaded content in a set value range. The seek bar is a specialised version of the slider.
 
-\subsection combobox Combobox
+\subsection combobox Combo box
 Class: MCombobox
 
-\image html combobox.png Combobox
-\image html combobox-open.png "Combobox opened"
+\image html combobox.png Combo box
+\image html combobox-open.png "Opened combo box"
 
-A combobox allows the user to select a value from a pop-up selection list.
+Allows the user to select a value from a pop-up list.
 
 \subsection progressindicator Progress indicator
 
-The progress indicator is used to show that an action is taking place and the expected duration thereof. If the duration
-is not known, the indicator can show this as well.
+Shows actions that are in progress and their expected durations. If the duration is not known, the indicator can show this as well.
 
 There are two types of progress indicators types:
 
 \image html progressbar.png "Progress indicator, bar"
-- Bar, a horizontal progress bar that fills up to completion, or indicates that the duration is unknown.
+- Bar, a horizontal progress bar that fills up when the action is complete or indicates that the duration is unknown.
 
 \image html spinner.png "Progress indicator, spinner"
-- Spinner, a circular progress indicator that fills up to completion, or indicates unknown duration.
+- Spinner, a circular progress indicator that fills up when the action is complete or indicates unknown duration.
 
 \subsection banner Banner
 Class: MBanner
 
 \image html banner.png Banner
 
-The banner provides a drop-in notification to the user on the screen that automatically disappears after a while.
-A banner created by an application is only visible in that single application. To create a system wide notification,
+Provides a drop-in notification to the user. A notification automatically disappears after a while.
+A banner created by an application is only visible in that specific application. To create a system-wide notification,
 use the MNotification API.
 
 */
diff --git a/doc/src/debugginginfo.dox b/doc/src/debugginginfo.dox
index d335d668..f57f2c8b 100644
--- a/doc/src/debugginginfo.dox
+++ b/doc/src/debugginginfo.dox
@@ -1,4 +1,4 @@
-/*! \page debugginginfo Debugging Information
+/*! \page debugginginfo Debugging functions
 
 \section intro_sec Introduction
 
@@ -14,7 +14,7 @@ Qt provides four functions for writing out warning and debug text:
 <li><a href="http://doc.qt.nokia.com/4.6/qtglobal.html#qFatal">qFatal()</a> is used for writing fatal error messages shortly before exiting.</li>
 </ul>
 
-In MeeGo Touch instead of qDebug() and qWarning() the functions mDebug() and mWarning() should be used, as mDebug() and mWarning() have been extended by a module name. This module name allows filtering of messages (see \ref outputprefix).
+In MeeGo Touch, use the functions mDebug() and mWarning() instead of qDebug() and qWarning(). The mDebug() and mWarning() functions have been extended by a module name which allows message filtering (see \ref outputprefix).
 
 Example:
 \verbatim
@@ -22,54 +22,54 @@ mDebug("MComponentData") << "Testability plugin loaded successfully";
 mWarning("MComponentData::setActiveWindow()") << "Attempting to activate unregistered window";
 \endverbatim
 
-Usually the module name is the name of the class with an optional method prefix.
+The module name is usually the name of the class with an optional method prefix.
 
-\section usage Usage
+\section usage Using debugging functions
 
-General guidelines:
+Use the debugging functions according to the following guidelines:
 <ul>
-<li>Try to use the debugging function with the lowest possible severity: mDebug() < mWarning() < qCritical() < qFatal(). E. g. do not use mWarning() for a custom debugging output.</li>
+<li>It is recommended that you use the debugging function with the lowest possible severity: mDebug() < mWarning() < qCritical() < qFatal(). For example, do not use mWarning() for a custom debugging output.</li>
 <li>Use debugging functions rarely.</li>
-<li>The text of the output should be basically understandable also for developers that do not maintain the module where the output has been triggered.
+<li>The text of the output should also be understandable for developers that do not maintain the module where the output has been triggered.
 </ul>
 
 \subsection mdebug mDebug()
 
-Is used for writing custom debug output. Consider to add only mDebug() statements that might be useful for future debugging. Remove all mDebug() statements that have been added for just fixing a current issue.
+Writes custom debug output. Add only mDebug() statements that are useful for future debugging. Remove all mDebug() statements that have only been added for fixing a current issue.
 
 \subsection mwarning mWarning()
 
-Is used to report warnings and recoverable errors. Only report a warning, if something unexpected happened that is not reported already by the API. E. g. do not report a warning if the parsing of some data failed and this failure is already reported by a return value. A warning is useful, if for example a caching mechanism cannot get activated and hence the performance might slow down dramatically. In this case the warning gives a hint about the root cause.
+Reports warnings and recoverable errors. Only report a warning for unexpected events that are not already reported by the API. For example, do not report a warning if the parsing of some data failed and the failure is already reported by a return value. A warning is useful, for example, if a caching mechanism cannot be activated and this may considerably slow down the performance. In this case, the warning gives a hint about the root cause.
 
 \subsection qcritical qCritical()
 
-Is used for writing critical error messages and reporting system errors. qCritical() instead of mWarning() should be used, if the functionality of the overall system might get harmed.
+Writes critical error messages and reports system errors. Use qCritical() instead of mWarning(), if the functionality of the overall system is at risk.
 
 \subsection qfatal qFatal()
 
-Is used for writing fata error messages shortly before exiting. Should only be used, if it is impossible to continue with the execution of further code (qFatal() will throw an exception).
+Writes fatal error messages shortly before exiting. Use this function only if it is impossible to continue with the execution of further code. The qFatal() throws an exception.
 
-\section controlling Controlling the Output
+\section controlling Controlling debugging output
 
-MeeGo Touch allows to control which messages are shown and to optionally stream the messages into a file.
+MeeGo Touch allows you to control which messages are shown and optionally stream the messages into a file.
 
 \subsection outputlevel -output-level
 
-Which messages are shown is specified by adding <em>-output-level {debug|warning|critical}</em> as parameter when starting an application or by setting the environment variable M_OUTPUT_LEVEL.
+To specify which messages are shown, add <em>-output-level {debug|warning|critical}</em> as parameter when starting an application or set the environment variable M_OUTPUT_LEVEL.
 <ul>
 <li>debug: Messages from qDebug(), mDebug(), qWarning(), mWarning(), qCritical() and qFatal() are shown.</li>
 <li>warning: Messages from qWarning(), mWarning(), qCritical() and qFatal() are shown.</li>
 <li>critical: Messages from qCritical() and qFatal() are shown.</li>
 </ul>
 
-If no output-level has been specified, on ARM environments <em>critical</em> is used as default value. In other environments <em>warning</em> is used as default.
+If no output-level has been specified, on ARM environments <em>critical</em> is used as the default value. In other environments <em>warning</em> is used as default.
 
 \subsection outputfile -output-file
 
-Per default the output is written to <em>stderr</em>. To stream the output into a file use <em>-output-file {filename}</em>.
+By default, the output is written to <em>stderr</em>. To stream the output into a file, use <em>-output-file {filename}</em>.
 
 \subsection outputprefix -output-prefix, -no-output-prefix
 
-It is possible to specify a whitelist or a blacklist of outputs with a specific prefix. The whitelist is specified by <em>-output-prefix {prefix}</em>, the blacklist is specified by <em>-no-output-prefix {prefix}</em>. The prefix is the given module name.
+You can specify a whitelist or blacklist for outputs with a specific prefix. To specify a whitelist, use <em>-output-prefix {prefix}</em>. To specify a blacklist, use <em>-no-output-prefix {prefix}</em>. The prefix is the given module name.
 
 */
diff --git a/doc/src/faststartup.dox b/doc/src/faststartup.dox
index 8a5beb4f..d05b9e71 100644
--- a/doc/src/faststartup.dox
+++ b/doc/src/faststartup.dox
@@ -1,34 +1,30 @@
-/*! \page faststart Fast application startup
+/*! \page faststart Reducing application start-up time
 
-There are three features that enable directly improving MApplication 
-startup times:
+You can directly improve MApplication start-up times with the following features:
 
 \li The \subpage launcher "application launcher" is the
-primary alternative for shortening application startup times. It will
-preload large libraries and instantiate e.g. MApplication and
-MApplicationWindow objects to so called component cache before the
-main() of the application is started. The application will then use
+primary alternative for reducing application start-up times. It 
+preloads large libraries and instantiates, for example, MApplication and
+MApplicationWindow objects to a so-called component cache before the
+main() of the application is started. The application then uses
 the already created instances from the component cache. However, there
-are some limitations to launcher usage. For instance it does not
-support some MeeGoTouch and Qt command line options.
+are some limitations to launcher usage. For instance, it does not
+support some MeeGo Touch and Qt command line options.
 
 \li \subpage prestart "Application prestarting" is meant for
-applications that cannot avoid slow initializations before they can be
-used. Prestarting enables starting up those applications to a state
-where they do not show UI. From that state they can show a window in
-no time when requested. This will provide the fastest results, but the
-drawback is the high memory usage due to prestarted applications as
-well as some unexpected maintenance tasks that the system may do for
-prestarted application processes. <strong>In Harmattan UI framework
+applications with slow initialisation times. Prestarting the applications brings them to a state
+where they do not show the UI. In that state the application window can be displayed immediately when requested. This provides the fastest results, but the
+drawback is the high memory usage caused by the prestarted applications. There may also be unexpected system maintenance tasks for the
+prestarted application processes. <strong>In the MeeGo Touch UI framework
 prestarting is limited to a small set of critical applications. This
 feature cannot be used without support from the system
 configuration.</strong>
 
 \li \ref prestart "Lazy shutdown" allows applications to
-be closed without terminating. This allows an application to show its
-window very quickly when it is needed next time. Lazy shutdown does
-not speed up the first startup at all, but it improves the performance
-of applications that take advantage of prestarting already.
+be closed without terminating them. The next time when the application is needed, the application 
+window is displayed very quickly. Lazy shutdown does
+not speed up the first start-up at all, but it improves the performance
+of applications that already take advantage of prestarting.
 
 An application can use any combination of the above features.
 
@@ -41,10 +37,10 @@ some \subpage responsivewindow "initial GUI" fast when starting the application.
 
 \section links Documentation links 
 
-    \li \ref launcher "How to write launchable applications"
+    \li \ref launcher "Writing launchable applications"
 
-    \li \ref prestart "How to write prestartable and lazy shutdownable applications"
+    \li \ref prestart "Writing prestartable and lazy shutdown applications"
 
-    \li \ref responsivewindow "How to show responsive window fast in meegotouch application"
+    \li \ref responsivewindow "Showing a responsive window quickly in a MeeGo Touch application"
 
 */
diff --git a/doc/src/gestures.dox b/doc/src/gestures.dox
index 5cf47a97..d78fb428 100644
--- a/doc/src/gestures.dox
+++ b/doc/src/gestures.dox
@@ -1,4 +1,4 @@
-/*! \page gestures Gestures and Multitouch
+/*! \page gestures Gestures and multipoint touch
 
 \section gesturesintro Gestures
 
@@ -40,46 +40,44 @@ A \a gesture is a high-level event that represents a series of user input. Qt an
 </tr>
 </table>
 
-As a gesture is merely an interpreted series of input, what the gesture actually means is up to the application.
+As a gesture is merely an interpreted series of input, the application determines what the gesture actually means.
 For example, a pinch gesture may be used to either rotate or zoom a picture, or both. If combined, gestures may
 have overlapping interactions, as is the case of swipe and pan. It is up to the application design to make sure
 there are no overlapping interactions in UI (the result of overlapping interactions is undefined). Typically a
 swipe gesture would be used in a UI where a flick should be interpreted as "next" or "previous", while a pan
 gesture implies an event with acceleration such as scrolling a web page.
 
-While all of the above gestures are touch activated, gestures can potentially use any type of input such
-as key events or sensor data. Using the QGestureRecognizer framework, it is possible to register new custom
+While all of the above gestures are touch-activated, gestures can potentially use any type of input such
+as key events or sensor data. You can use the QGestureRecognizer framework to register new custom
 gesture types.
 
 \section usedgestures Gestures used by MeeGo Touch
 
 While gesture events are mainly meant for application consumption, the MeeGo Touch UI design guidelines
-does specify some default actions based on gestures. Unless you as an application developer override the behavior,
+ specify some default actions based on gestures. Unless the application developer overrides the behaviour,
 gestures may be consumed by the framework itself in the following cases:
 - The MPannableViewport consumes QPanGesture events, most commonly in the case of a pannable MApplicationPage (pages are pannable by default).
-- Any MWidget with one or more QActions or MActions added (using QGraphicsWidget::addAction) will consume a QTapAndHoldGesture and open the contextual \a "Object Menu" for the widget when the gesture completes.
+- Any MWidget with one or more QActions or MActions added (using QGraphicsWidget::addAction) consumes a QTapAndHoldGesture and opens the contextual \a "Object Menu" for the widget when the gesture completes.
 
-\section multitouch Multitouch
+\section multitouch Multipoint touch
 
-While some of the gestures mentioned above like pinch are implemented using multitouch events,
-by itself multitouch merely refers to the capability to detect several fingers on the screen at once.
-Multitouch events are also directly accessible by applications in a low-level form comparable to mouse and
-key presses and releases, where the actual interpretation of the events is left entirely up to you.
+While some of the gestures mentioned above (such as pinch) are implemented using multipoint touch events,
+by itself multipoint touch merely refers to the capability of detecting several fingers on the screen at once.
+Multipoint touch events are also directly accessible by applications in a low-level form comparable to mouse and
+key presses and releases, where the actual interpretation of the events is left entirely up to you. Note: Multipoint touch requires special hardware to function, since many touch input devices are not capable of detecting multiple touch points at once.
 
-Note that multitouch requires special hardware to function, many touch input devices do not support the
-capability to detect multiple touch points at once.
+In Qt, multipoint-touch input is delivered through the QTouchEvent class, through which it is possible to determine
+all the currently touched screen points. 
 
-In Qt, multitouch input is delivered through the QTouchEvent class, through which it is possible to determine
-all the currently touched screen points. Note that by default multitouch events are not delivered
-to widgets, delivery must explicitly be enabled using the QGraphicsItem::setAcceptTouchEvents method.
+Note: Since multipoint touch events are not delivered to widgets by default, the delivery must be explicitly enabled with the QGraphicsItem::setAcceptTouchEvents method.
 
-\section simulatingmultitouch Simulating multitouch
+\section simulatingmultitouch Simulating multipoint touch
 
-You can simulate the multitouch pinch gesture without needing real multitouch hardware,
-for example in a development environment on a standard PC. Simply hold down the
+You can simulate the multipoint touch pinch gesture without real multipoint-touch hardware,
+for example, in a development environment on a standard PC. Simply hold down the
 <Ctrl> key on the keyboard, then press and drag with the left mouse button.
 
-\section gesturesinmtf Gestures related API in MeeGo Touch
+\section gesturesinmtf APIS related to gestures
 
 MeeGo Touch provides several event handlers for gestures:
 
@@ -91,29 +89,28 @@ MeeGo Touch provides several event handlers for gestures:
 - MWidget::swipeGestureEvent
 
 These event handlers can be re-implemented to act upon all or specific gestures, in the same way as the existing
-methods QGraphicsItem::mousePressEvent, QGraphicsItem::mouseReleaseEvent and so on.
+methods QGraphicsItem::mousePressEvent, QGraphicsItem::mouseReleaseEvent, and so on.
 
-There are also corresponding methods in both the MWidgetController and the MWidgetView for use when extending or writing
+There are also corresponding methods in both the MWidgetController and the MWidgetView for extending or writing
 new MeeGo Touch common components.
 
 Gestures are not delivered to widgets by default, gesture delivery is enabled by the QGraphicsObject::grabGesture method.
 
 MeeGo Touch currently replaces some of the default Qt gesture recognizers with versions capable of
-intepreting regular mouse events in addition to the touch events used by Qt. Pan and swipe are also
-one-finger gestures in MeeGo Touch while they are 2 and 3 finger gestures respectively in Qt (as of version 4.7).
+interpreting regular mouse events in addition to the touch events used by Qt. Pan and swipe are also
+one-finger gestures in MeeGo Touch, while they are two- and three-finger gestures, respectively, in Qt (as of version 4.7).
 
-\section gestureexample Gestures Example & Tips for Apps
+\section gestureexample Gestures examples and tips for applications
 
 The examples/gestures directory of the MeeGo Touch source contains a sample application demonstrating proper use of
-gestures combined with MeeGo Touch widgets. The example is of a gallery type of application, where pinching the picture
-zooms and rotates simultanously, while swiping left or right changes the picture.
+gestures combined with MeeGo Touch widgets. The example is a gallery application, where pinching zooms and rotates the picture simultaneously, while swiping left or right changes the picture.
 
-Notable points of the example:
+The example below illustrates the following:
 - Enabling multitouch handling through setAcceptTouchEvents(true);
 - Enabling gesture delivery through grabGesture
 - Transforming the picture by calculating the rotation and scale factors using the pinch
-- The ease of detecing and acting on a swipe gesture
-- Best practices of detecing the gesture on the largest surface available
+- The ease of detecting and acting on a swipe gesture
+- Best practices of detecting the gesture on the largest surface available
 
 Below is the example code relevant to the gestures:
 
diff --git a/doc/src/i18n.dox b/doc/src/i18n.dox
index a54c0f64..f4ed4cc7 100644
--- a/doc/src/i18n.dox
+++ b/doc/src/i18n.dox
@@ -1,32 +1,27 @@
-/*! \page  i18n  Internationalisation Guidelines
+/*! \page  i18n  Internationalisation
 
 \htmlinclude i18n-toc.html
 
 \section  intro  Introduction
 
-This document provides guidelines on developing locale-aware
-applications for the MeeGo Touch UI Framework. Developers, translators, and
-user interface designers are the main target audience of this
-document.
+This section provides guidelines for developing locale-aware applications for the MeeGo Touch UI 
+Framework. The guidelines are mainly intended for developers, translators, and user interface 
+designers.
 
-Generally, as the MeeGo Touch UI Framework uses Qt as it’s base, some
-of the Qt internationalisation practices also apply. However, the
-MeeGo Touch UI Framework provides additional functionalities, hence it
-is recommended that developers always use MeeGo Touch UI Framework
-classes to achieve full internationalisation support in their
-applications.
+Generally, as the MeeGo Touch UI Framework uses Qt as its base, some of the Qt 
+internationalisation practices also apply. However, since the MeeGo Touch UI Framework provides 
+additional functionalities, it is recommended that developers always use MeeGo Touch UI Framework
+classes to achieve full internationalisation support in their applications.
 
-This document discusses several general internationalisation
-guidelines for user interface designers. They are general enough and
-may also be applicable in another projects and vice versa.
+The general internationalisation guidelines for user interface designers can also be applied 
+to other projects.
 
 \section  architecture  Architecture
 \image html i18n-class.png "" 
 
-\section  supportedlanguages  Supported Languages and calendar systems
+\section  supportedlanguages  Supported languages and calendar systems
 
-Below is the list of officially supported languages both for writing
-systems and text rendering:
+The following languages are officially supported both for writing systems and text rendering:
 
 - <a href="http://en.wikipedia.org/wiki/American_english">American English</a>
 - <a href="http://en.wikipedia.org/wiki/Arabic_language">Arabic</a>
@@ -83,102 +78,91 @@ The MeeGo Touch UI locale system uses the following main settings:
   </caption>
   <tr>
      <th>gconf key</th>
-     <th>description</th>
-     <th>example value</th>
+     <th>Description</th>
+     <th>Example value</th>
   </tr>
   <tr>
   <td>/meegotouch/i18n/language</td>
-  <td>main language setting</td>
+  <td>Main language</td>
   <td>en_US</td>
   <tr>
   <td>/meegotouch/i18n/lc_time</td>
-  <td>for date, time, and calendar</td>
+  <td>Date, time, and calendar</td>
   <td>ar\@calendar=islamic</td>
   </tr>
   <tr>
   <td>/meegotouch/i18n/lc_collate</td>
-  <td>for sorting</td>
+  <td>Sorting</td>
   <td>de_DE\@collation=phonebook</td>
   </tr>
   <tr>
   <td>/meegotouch/i18n/lc_numeric</td>
-  <td>formatting of numbers</td>
+  <td>Number format</td>
   <td>hi</td>
   </tr>
   <tr>
   <td>/meegotouch/i18n/lc_monetary</td>
-  <td>for formatting of amounts of money</td>
+  <td>Currency format</td>
   <td>fi_FI\@currency=EUR</td>
   </tr>
 </table>
 
-Each of these settings can be set to a ICU locale specifier as
-described in the <a href="http://userguide.icu-project.org/locale">ICU
-User Guide</a>.
+Each of these settings can be set to an ICU locale specifier. For instructions, see <a href="http://userguide.icu-project.org/locale">ICU User Guide</a>.
 
-The value of \c /meegotouch/i18n/language  (“Language”) tells the locale system
-about the UI language of the device. This affects all UI texts,
-writing direction and widget layouts (It does not affect the user
-content, i.e.  it does not affect things like the browser content
-language etc.).
+The value of \c /meegotouch/i18n/language  (“Language”) tells the locale system the UI language of the device. This affects all UI texts, the
+writing direction and widget layouts. However, it does not affect the user content, such as the language for the browser content.
 
 “Language” is also used as the default for time, date, calendar,
-sorting, number formatting, and currency formatting if the more
+sorting, number format, and currency format if the more
 specific settings are empty.
 
-“LcTime” selects how time and date are formatted. If it is left empty
-the value of “Language” is used. Examples: \c ar\@calendar=islamic  means
-to format date and time the Arabic way using Islamic calendar,
-\c ar\@calendar=gregorian  would use Arabic formatting but with Gregorian
-calendar, \c fi_FI  would use Finnish formatting rules for time and
-date.
-
-“LcCollate” selects how textual data is sorted. If it is left empty
-the value of “Language” is used. Examples: \c de_DE\@collation=phonebook
-sorts the way German phone books are sorted,
-\c de_DE\@collation=standard  (or \c de_DE ) sorts the “normal” way German
+“LcTime” selects how time and date are formatted. If it is left empty,
+the value of “Language” is used. For example, \c ar\@calendar=islamic uses Arabic date and time 
+formats with the Islamic calendar, \c ar\@calendar=gregorian uses Arabic date and time formats with 
+the Gregorian calendar, and \c fi_FI uses Finnish formatting rules for time and date.
+
+“LcCollate” selects how textual data is sorted. If it is left empty, the value of “Language” 
+is used. Examples: \c de_DE\@collation=phonebook sorts in the way German phone books are sorted,
+\c de_DE\@collation=standard  (or \c de_DE ) sorts in the “normal” way German
 dictionaries are sorted. \c zh_CN\@collation=pinyin  sorts Chinese
 according to the pinyin phonetics, \c zh_CN\@collation=stroke  sorts
 Chinese according to the stroke count of the characters.
 
-“LcNumeric” selects how numbers are formatted. If it is left empty the
-value of “Language” is used. Examples: \c hi  formats numbers according
-to the rules for the Hindi language, using localized digits, i.e. <a
+“LcNumeric” selects how numbers are formatted. If it is left empty, the
+value of “Language” is used. Examples: \c hi  formats numbers according to the rules for the Hindi language, using localised digits. In other words, <a
 href="http://en.wikipedia.org/wiki/Indian_numerals">Devanagari
-numerals</a> (०,१,२,३,४,५,६,७,८,९), \c ar  formats numbers
-using <a
+numerals</a> (०,१,२,३,४,५,६,७,८,९) \c ar  formats numbers using <a
 href="http://en.wikipedia.org/wiki/Eastern_Arabic_numerals">Eastern
-Arabic numerals</a> (٠,١,٢,٣,٤,٥,٦,٧,٨,٩), \c de_CH  formats the Swiss
-German way with apostrophes as thousands separators (12'345'670.89),
+Arabic numerals</a> (٠,١,٢,٣,٤,٥,٦,٧,٨,٩), \c de_CH  formats according to Swiss German by using apostrophes to separate thousands (12'345'670.89),
 and \c en_US  formats the American English way (12,345,670.89).
 
 “LcMonetary” selects how currency amounts are formatted. If it is left
-empty the value of “Language” is used.
+empty, the value of “Language” is used.
 
 \subsection  localesysteminitialisation  Initialisation
 
-A MeeGo Touch UI application is normally using the system default MLocale object;
+A MeeGo Touch UI application normally uses the system default MLocale object:
 
 \code
 MLocale myLocale; // get the current locale
 \endcode
 
 If the application needs to use different locale settings than the
-system locale, then a MLocale is created by making an instance of a
-MLocale object:
+system locale, an MLocale is created by making an instance of a
+MLocale object. For example:
 
 \code
 MLocale locale ("fi_FI");
 \endcode
-where "fi" and "FI" mean to use Finnish language in Finland.
+where "fi" and "FI" define that the Finnish language in used in Finland.
 
 \subsection Collator Collator
-To do collation, get the comparator with \c MLocale::collator()  method or create it MCollator() for default locale collator. This object acts as a functor and can be passed to Qt's \c qSort()  or any other sorting methods. 
-The comparator basically does the comparison of two items as "lessThan" function and returns true if the first parameter should come before the second one. 
+To collate, get the comparator with \c MLocale::collator() method or create it MCollator() for default locale collator. This object acts as a functor and can be passed to Qt's \c qSort() or any other sorting methods. 
+The comparator basically compares two items as "lessThan" function and returns true if the first parameter should come before the second one. 
 
-If other collation system than the locale's default is needed, then use \c setCollation()  method before getting the comparator. After all are set then the sorting can be started by using Qt's \c qSort()  function.
+If some other collation system than the locale's default is needed, use \c setCollation() method before getting the comparator. To start sorting, use Qt's \c qSort()  function.
 
-To use the default collation:
+To use the default collation system:
 \code
 QStringList sl; // This contains the strings which need to be sorted
 ...
@@ -189,7 +173,7 @@ qSort(sl.begin, sl.end, c); // start to sort!
 ...
 \endcode
 
-To use the different collation:
+To use a different collation system:
 \code
 QStringList sl; // This contains the strings which need to be sorted
 ...
@@ -205,11 +189,11 @@ qSort(sl.begin, sl.end, c); // start to sort!
 
 MeeGo Touch UI comes with several formatters for several data
 types. (Almost) Always use the formatters before displaying
-locale-dependant data to the screen to achieve uniformity and
-consistency of the data presentation.
+locale-dependant data on the screen to achieve uniformity and
+consistency in the data presentation.
 
 \subsubsection  numbers  Numbers
-To format a number use \c formatNumber()  method. It works with \c qlonglong, \c short, \c int, \c double, and \c float  data types.
+Use \c formatNumber()  method to format numbers. It works with \c qlonglong, \c short, \c int, \c double, and \c float  data types.
 
 \code
 ...
@@ -221,7 +205,7 @@ QString formattedNumber = myLocale.formatNumber(number); // format the number, t
 \endcode
 
 \subsubsection  dateandtime  Date and time
-Use \c formatDateTime()  to format the date and time.
+Use \c formatDateTime()  method to format the date and time.
 \code
 ...
 MLocale myLocale; // get the current locale
@@ -245,7 +229,7 @@ QString formattedDateTime = myLocale.formatDateTime(now, MLocale::IslamicCalenda
 Custom formatting is supported with ISO-14652 format (also used in libc's \c strftime ) by using \c formatDateTime() .
 
 \subsubsection  percentage  Percentage
-\c formatPercent()  is used to format a percentage value.
+Use \c formatPercent()  method to format a percentage value.
 \code
 ...
 MLocale myLocale; // get the current locale
@@ -257,7 +241,7 @@ QString formattedPercentage = myLocale.formatPercent(percent, decimals);
 \endcode
 
 \subsubsection Currency Currency
-To format any amount of money with a currency, use \c formatCurrency()  method.
+Use \c formatCurrency()  method to format amounts of money.
 
 
 \code
@@ -277,7 +261,7 @@ Use MName class to populate the name information, and use \c MLocale::formatName
 Use MAddress class to populate the address information, and use \c format()  method to format the name using the format specified as parameter.
 
 \subsection Calendar Calendar
-MLocale provides Gregorian as well as non-Gregorian calendar support. Use \c formatDateTime()  to format the date according to the custom of the selected calendar.
+MLocale provides Gregorian as well as non-Gregorian calendar support. Use \c formatDateTime()  method to format the date according to the selected calendar.
 To set another calendar than the default Gregorian calendar, use \c setCalendarType()  method.
 
 \code
@@ -287,10 +271,10 @@ myLocale.setCalendarType(MLocale::IslamicCalendar); // set the calendar to use I
 ...
 \endcode
 
-Further date manipulations can be done using MCalendar object.
+To change other calendar settings, use the MCalendar object.
 
 \subsection  iteratingwords  Iterating words
-On general case iterating words in a string is not possible by searching whitespace: e.g. thai language just concatenates words and in chinese language a character is a word. For this need a MBreakIterator class can be used. It is constructed with a locale and a string and provides an interface for iterating word boundaries. Following example iterates word boundaries from beginning to the end:
+In general, it is not possible to iterate words in a string by searching whitespace. For example, the Thai language just concatenates words and in the Chinese language one character is a word. Thus, an MBreakIterator class can be used. It is constructed with a locale and a string, and it provides an interface for iterating word boundaries. The following example iterates word boundaries from beginning to end:
 
 \code
 MLocale myLocale; // current locale
@@ -306,20 +290,18 @@ while (iterator.hasNext()) {
 \subsection  logicalidandengineeringenglish  Logical ID and engineering English
 
 The MeeGo Touch UI Framework can use both the Qt standard \c tr()  method or the
-idbased
+ID-based
 <a href="http://qt.nokia.com/doc/qtglobal.html#qtTrId">qtTrId()</a>
 method. For the Nokia internal localisation process, only \c qtTrId() 
 should be used.  Other parties using logical IDs instead of
-engineering English IDs for the UI messages might also find \c qtTrId() 
+engineering English IDs for the UI messages may also find \c qtTrId() 
 useful.
 
-Contrary to the approach of using engineering English as the message
-ids, which is commonly used in the open source community, the
-logical ID approach uses message ids which are guaranteed to be
-globally unique.
+Engineering English is commonly used as the message IDs in the open source community. However, the
+logical ID approach uses message IDs which are guaranteed to be globally unique.
 
 With \c qtTrId(), the logical ID is an argument of the function and the
-engineering English is supplied as a comment above. See the example in
+engineering English is supplied as a comment above. For an example, see
 the Qt documentation of
 <a href="http://qt.nokia.com/doc/4.6-snapshot/qtglobal.html#qtTrId">qtTrId()</a>,
 reproduced here for convenience:
@@ -330,17 +312,17 @@ reproduced here for convenience:
    QString text = qtTrId("qtn_foo_bar", n);
 \endcode
 
-\subsection  generatingengineeringenglish Generating the engineering English .qm files
+\subsection  generatingengineeringenglish Generating engineering English .qm files
 
-If no translation files at all are available, \c qtTrId() would return
-the logical ID which looks pretty ugly and is not nice for testing the
-user interface.
+If there are no translation files available at all, \c qtTrId()  returns
+the logical ID. However, this does not look good and makes testing the
+user interface more difficult.
 
-But from code which uses \c qtTrId() with the special engineering
+However, if the code uses \c qtTrId() with the special engineering
 English comments, \c .qm files with engineering English translations
-can be generated automatically. This can be done as follows:
+can be generated automatically. To generate files automatically:
 
-Create a subdirectory \c translations/ somewhere in your source tree.
+1. Create a subdirectory \c translations/ somewhere in your source tree.
 In that folder, create a \c translations.pro file with the contents:
 
 \code
@@ -352,10 +334,9 @@ In that folder, create a \c translations.pro file with the contents:
     include($$[QT_INSTALL_DATA]/mkspecs/features/meegotouch_translations.prf)
 \endcode
 
-Introducing the extra \c translations/translations.pro file makes it
-necessary to add the \c translations/ directory to the
-list of sub-directories in a .pro file higher up in the directory
-hierarchy. I.e. you usually need something like 
+2. After creating the extra \c translations/translations.pro file, add the \c translations/ 
+directory to the list of sub-directories in a .pro file higher up in the directory hierarchy. 
+For example:
 
 \code
    SUBDIRS = \
@@ -364,30 +345,28 @@ hierarchy. I.e. you usually need something like
        ...
 \endcode
 
-After doing that, a \c foobar.ts and a \c foobar.qm file which
-contain the engineering English translations will be automatically
-generated when calling “make” for your project. And “make install”
-will install \c foobar.qm to the usual place as described
-in section \ref translationdatastorage.
+A \c foobar.ts and a \c foobar.qm file which contain the engineering English translations are 
+automatically generated when calling “make” for your project. Additionally, “make 
+install” installs \c foobar.qm to the usual place. For more information, 
+see \ref translationdatastorage.
 
 Minor detail: with the above setup, when creating \c foobar.qm from \c
 foobar.ts, lrelease uses the option \c -markuntranslated to prepend
 the string “!! ” at the beginning of each engineering English
-string. I.e.  if the engineering English string in the source code is
-“Hello”, it will be written as “!! Hello” into the \c foobar.qm file
-and will be displayed as “!! Hello” at runtime. This is to make it
+string. This means that if the engineering English string in the source code is
+“Hello”, it is written as “!! Hello” into the \c foobar.qm file
+and displayed as “!! Hello” at runtime. Thus, it makes it
 obvious that engineering English for testing purposes is displayed and
-not the “real” English which is done by the translators.
+not “real” English translations.
 
-\subsection  translationsystemsetup  Translation system setup
+\subsection  translationsystemsetup  Setting up a translation system
 
-To setup the translation system using \c qtTrId(), you
+To set up a translation system using \c qtTrId(), you
 can use the following code snippets in your main function:
 
 By default, the system uses the name of the application executable
-(without the directory path) as the name for the file of the
-translation catalog and loads this catalog automatically. So you can
-start using \c qtTrId()  immediately:
+(without the directory path) as the name for the translation catalog file and loads this catalog 
+automatically. Thus, you can immediately start using \c qtTrId():
 
 \code
 ...
@@ -402,15 +381,14 @@ int main(int argc, char** argv){
 ...
 \endcode
 
-In the above example, if the application executable is for example
-\c /usr/bin/foo, i.e. the base file name of the executable is \c foo, the
-translation catalog \c &lt;top-directory&gt;/foo_&lt;locale-code&gt;.qm  will be
+In the above example, if the application executable is, for example,
+\c /usr/bin/foo, which means that the base file name of the executable is \c foo, the
+translation catalog \c &lt;top-directory&gt;/foo_&lt;locale-code&gt;.qm is
 used.
 
-If you need to specify a file for the translation catalog wich differs
-from the name of the executable you can use the optional third
-parameter \c appIdentifier  of the MApplication constructor as in this
-example:
+If you need to specify a file for the translation catalog which does not have the same
+name as the executable, you can use the optional third parameter \c appIdentifier of the 
+MApplication constructor. For example:
 
 \code
 ...
@@ -426,18 +404,16 @@ int main(int argc, char** argv){
 \endcode
 
 In the above example, the translation catalog
-\c &lt;top-directory&gt;/bar_&lt;locale-code&gt;.qm will be used no matter
-what the file name of the application executable is.
+\c &lt;top-directory&gt;/bar_&lt;locale-code&gt;.qm is used, regardless of the file name of the 
+application executable.
 
-But note that the \c appIdentifier  is used not only for localization
-files but also for themes. I.e. changing the appIdentifier
-will also affect themes. Usually this should be no problem because
+Note: In addition to localisation files, the \c appIdentifier is also for themes. This means that 
+if you change the appIdentifier, it also affects themes. This is usually not a problem because
 in most cases these should be kept the same, if possible.
 
-When it is not possible to use the \c appIdentifier to specify the
-translation catalog which should be loaded, one can use the
-\c installTrCatalog()  function to load a translation catalog with a
-completely different name as in this example:
+When it is not possible to use the \c appIdentifier to specify which translation catalog is 
+loaded, use the \c installTrCatalog()  function to load a translation catalog with a completely 
+different name. For example:
 
 \code
 ...
@@ -471,9 +447,8 @@ int main(int argc, char** argv){
 ...
 \endcode
 
-To setup your translation using the \c tr()  method known from regular Qt
-programs, you can use the \c installTrCatalog()  method as in the
-following example:
+To set up your translation using the \c tr()  method used in regular Qt
+programs, you can use the \c installTrCatalog()  method. For example:
 
 \code
 ...
@@ -502,16 +477,13 @@ int main(int argc, char** argv){
 ...
 \endcode
 
-\subsection translationsystemsetupinlibraries Translation system setup in libraries
+\subsection translationsystemsetupinlibraries Setting up a translation system in a library
 
-Let’s say there is an MApplication “foo” which uses a library “libbar”.
-And the library “libbar” also uses the MeeGo Touch Framwork and has
-some translations of its own which are in files like \c libbar_<locale_name>.qm.
+This section provides an example of setting up a translation system in a library. In this example, MApplication “foo” uses a library “libbar”, which also uses the MeeGo Touch Framework and has its own translations in files such as \c libbar_<locale_name>.qm.
 
-Now the question is how to load the “libbar” translation catalog.
+There are several ways to load the “libbar” translation catalog.
 
-On way to do it would be to let the application “foo” load it, i.e.
-“foo” would do something like 
+For example, you can let the application “foo” load it:
 
 \code
 ...
@@ -547,13 +519,11 @@ int main(int argc, char** argv){
 ...
 \endcode
 
-The disadvantage of this way of doing it is that the application “foo”
-needs to know how the translation catalog of “libbar” is called and
-maybe even require an packages like “libbar-l10n-*”. That creates
-unnecessary dependencies between “foo” and “libbar”. To avoid this,
-the recommended way of loading the “libbar” translations is letting
-the “libbar” library take care of this. I.e. “libbar” somewhere has
-an initialization function like
+However, the application “foo” needs to know how the translation catalog of “libbar” is 
+called and may even require packages such as “libbar-l10n-*”, which creates unnecessary 
+dependencies between “foo” and “libbar”. Thus, it is recommended that you let
+the “libbar” library load the “libbar” translations. This means that “libbar” includes 
+the following initialisation function:
 
 \code
 ...
@@ -569,7 +539,7 @@ void libbar_init() {
 ...
 \endcode
 
-The application “foo” then does not have to load the translations for “libbar”
+Thus, the application “foo” does not have to load the translations for “libbar”
 and only does:
 
 \code
@@ -598,10 +568,10 @@ int main(int argc, char** argv){
 ...
 \endcode
 
-Instead of having a public initialization function in “libbar” one could also
-make “libbar” call some internal initialization code when any public
-function of “libbar” is used for the first time, i.e. one could design
-“libbar” to make the following code already work:
+Instead of having a public initialisation function in “libbar”, you can also
+make “libbar” call some internal initialisation code when any public
+function of “libbar” is used for the first time. This means that you can design
+“libbar” so that the following code works:
 
 \code
 ...
@@ -627,8 +597,8 @@ int main(int argc, char** argv){
 ...
 \endcode
 
-Whether a special initialization function is used or not, the important
-thing is that “libbar” does the installing of its translation catalog
+Whether a special initialisation function is used or not, the important
+thing is that “libbar” installs its translation catalog
 into the system default locale. The application “foo” then does
 not need to know how the catalog is called and does not need to require
 translation packages of “libbar”. “libbar” should require its translation
@@ -650,42 +620,38 @@ n. In addition, depending on \c n’s value, the translation text may
 vary.
 
 The difference between \%Ln and \%n is that \%Ln may be replaced using
-localized numerals like Arabic-Indic numerals in Arabic locales
+localised numerals such as Arabic-Indic numerals in Arabic locales,
 whereas \%n is always replaced using Arabic (= Western) numerals.
 
 <a
 href="http://qt.nokia.com/doc/qtglobal.html#qtTrId">qtTrId()</a>
-is useful only if the project is using logical names as the UI
-message. If your project is using English string then use \c tr()
+is useful only if the project is using logical names such as the UI
+message. If your project is using an English string, use \c tr()
 instead.
 
 \subsection parametersintranslations Parameters in translations
 
 The positional parameters \%1 to \%99 and \%L1 to \%L99 which are used in
 QString can also be used in translations for the MeeGo Touch UI
-Framework.
-For a description of \%L1 to \%L99 see also the documentation
+Framework. For a description of \%L1 to \%L99, see also the documentation
 of QLocale.
 
-For parameters which are integer numbers, \%L1 to \%L99 is a better
+For parameters which are integer numbers, \%L1 to \%L99 are a better
 choice than \%1 to \%99 because \%L1 to \%L99 automatically do locale
 specific number formatting which achieves the same results
 as using MLocale’s formatNumber() for the current system locale.
 
-Let’s illustrate the behaviour in detail with an example.  We assume
-that an application is running with the language locale settings set
-to Arabic to get Arabic translations (for example if the gconf key
+For example, if an application is running with the language locale settings set
+to Arabic to get Arabic translations (for example, if the gconf key
 “/meegotouch/i18n/language” is set to “ar”) and the numeric locale
 settings are also set to Arabic to get Arabic number formatting (for
-example if the gconf key “/meegotouch/i18n/lc_numeric” is also set
-to “ar” or is empty and this the numeric locale settings are
+example, if the gconf key “/meegotouch/i18n/lc_numeric” is also set
+to “ar” or is empty and the numeric locale settings are
 inherited from the language settings).
 
-Now a message id is translated using qtTrId("xx_some_message_id"). And
-let’s assume that the Arabic translation of this happens to be “\%L1 \%2”.
-
-The following example code illustrates how numbers used as parameters
-would be formatted in that case:
+If a message ID is translated using qtTrId("xx_some_message_id"), and the Arabic translation of 
+this is “\%L1 \%2”, the following example code illustrates how numbers used as parameters
+are formatted:
 
 \code
     QString translation = qtTrId("xx_some_message_id");
@@ -724,20 +690,19 @@ would be formatted in that case:
     // Therefore, no further formatting is done by %L1 and %2.
 \endcode
 
-Passing an integer number as the argument from %L1 and letting QLocale
-format that number always gives the same result as passing the the
+If you pass an integer number as the argument from %L1 and let QLocale
+format that number, this always gives the same result as if you pass the
 result of formatNumber() using the system MLocale for that integer.
-The reason is that the MeegoTouch framework always sets QLocale to the
+The reason is that the MeeGo Touch Framework always sets QLocale to the
 value of the numeric setting of the system default MLocale and both
 the number formatter in MLocale and the number formatter in QLocale
 use the CLDR data for the number format.
 
-\subsection placeholdersinmessageids Place holders in message ids
+\subsection placeholdersinmessageids Placeholders in message IDs
 
-Message ids do not have to indicate whether the translation for this
-id contains place holders or not. For example if the message id is
-“xx_greet_user" and the English translation is “Hello %1”,
-then the following code works fine:
+Message IDs do not have to indicate whether the translation for this
+ID contains placeholders or not. For example, if the message ID is
+“xx_greet_user" and the English translation is “Hello %1”, the following code works fine:
 
 \code
    // The following returns “Hello Joe” if the translation is “Hello %1”.
@@ -745,10 +710,10 @@ then the following code works fine:
    qTrId("xx_greet_user").arg("Joe");
 \endcode
 
-It is possible to include place holders in message ids,
-for example if the message id for the translation
-were “xx_greet_user_%1”, the following code would
-work just as well:
+It is possible to include placeholders in message IDs.
+For example, if the message ID for the translation
+is “xx_greet_user_%1”, the following code 
+works just as well:
 
 \code
    // The following returns “Hello Joe” if the translation is “Hello %1”
@@ -756,22 +721,22 @@ work just as well:
    qTrId("xx_greet_user_%1").arg("Joe");
 \endcode
 
-So it doesn’t matter whether a message id for a translation which
-contains place holders contains these place holders itself or not.
+Thus, it does not matter whether the placeholders are included in the actual message ID for a translation that
+contains the placeholders.
 
-Although place holders in message ids are possible, the message ids
-used by MeeGo Touch never contain any place holders. The message
-ids used in MeeGo Touch only use lowercase letters
+Although placeholders in message IDs are possible, the message IDs
+used by MeeGo Touch never contain any placeholders. The message
+IDs used in MeeGo Touch only use lowercase letters
 from “a” to “z” and underscores “_”. 
 
 This is perfectly OK and does not cause any problems for
-translations which use place holders.
+translations which use placeholders.
 
 \subsection  pluralmessages  Plural messages
 
 In a plural message, pass the number to select the correct
-plural translation as the second argument \c n  in \c qtTrId()
-(This works the same way with qtTrId() as it does with \c tr()).
+plural translation as the second argument \c n  in \c qtTrId().
+This works the same way with qtTrId() as it does with \c tr().
 
 \code
    int n = messages.count();
@@ -779,22 +744,20 @@ plural translation as the second argument \c n  in \c qtTrId()
    showMessage(qtTrId("xx_messages_saved", n));
 \endcode
 
-Usually, the number of different translations used for plural, among
-which the parameter “n” selects the appropriate one, depends on the
-language, see also the <a
+Some languages have several plural forms. For these languages, the parameter “n” selects the appropriate translation. For more information, see the <a
 href="http://qt.nokia.com/doc/i18n-plural-rules.html">“Qt
 Translation Rules for Plurals”</a> and the <a
 href="http://unicode.org/repos/cldr-tmp/trunk/diff/supplemental/language_plural_rules.html">“CLDR
 Language Plural Rules”</a>.
 
-However, for the Meego Touch UI framework, it has been decided to use
-only 2 plural forms and only English rules. I.e.  the .ts translation
-files used by the Meego Touch UI framework <b>always</b> contain
+However, for the MeeGo Touch UI Framework, it has been decided to use
+only 2 plural forms and only English rules. This means that the .ts translation
+files used by the MeeGo Touch UI Framework <b>always</b> contain
 <b>only two</b> different translations for plural and are
 <b>always</b> marked in the xml as English language translation files,
 even if the language is not English.
 
-For example if a .ts file for English translation contains something like
+For example, if a .ts file for the English translation contains the following:
 
 \code
 <?xml version="1.0" encoding="UTF-8"?>
@@ -822,8 +785,7 @@ For example if a .ts file for English translation contains something like
 </TS>
 \endcode
 
-the corresponding Russian translation file might contain
-something like:
+The corresponding Russian translation file contains the following:
 
 \code
 <?xml version="1.0" encoding="UTF-8"?>
@@ -851,34 +813,33 @@ something like:
 </TS>
 \endcode
 
-Note that this Russian translation file has “language="en"”
-in the header and thus English rules are used to select
-the plural forms, i.e. the first plural form is selected
-if “n” is equal to 1, the second plural form for all
+Note: This Russian translation file has “language="en"”
+in the header. Thus, English rules are used to select
+the plural forms. This means that the first plural form is selected
+if “n” is equal to 1, and the second plural form is selected for all
 other cases.
 
-Usually, Russian would use one plural form for　“n” in 1, 21, 31,
+Usually, Russian uses one plural form for　“n” in 1, 21, 31,
 41, 51, 61…, another one for “n” in 2-4, 22-24, 32-34…, and yet
 another one for “n” in 0, 5-20, 25-30, 35-40….
 
-If only 2 forms with English rules are used as above, i.e.
-only “n” equal to 1 is special cased, the second plural
+If only 2 forms with English rules are used as above, this means that
+only “n” equal to 1 is special cased and the second plural
 form has to be translated in a way that it is acceptable
 for all other values of “n”.
 
-In the Russian example translation file above this is in one case
-achieved by abbreviating, i.e. using “\%Ln дн.” for all “n” not
-equal to one and thus hide the different plural forms with the
-abbreviation dot. In the other case, the number is grammatically
-“detached”, i.e. by writing “Событий: \%Ln” the part of the
-translation before the “:” is detached from the part with the number
-and thus the word “Событий” does not need to change for
-different values of “n”.
+In the Russian example translation file above, this is, first of all,
+achieved by abbreviating. In other words, “\%Ln дн.” is used for all “n” that are not
+equal to one, thus hiding the different plural forms with the
+abbreviation dot. Secondly, the number is grammatically
+“detached”. This means that if you write “Событий: \%Ln”, the part of the
+translation before the “:” is detached from the part with the number, and the word 
+“Событий” does not need to change for different values of “n”.
 
-\subsubsection percent_ln_percent_l1 \%Ln versus \%L1 in plural messages
+\subsubsection percent_ln_percent_l1 \%Ln and \%L1 in plural messages
 
-Messages using plural should use the place holder \%Ln
-and not \%L1, i.e. the source code should should look like
+Use the placeholder \%Ln and not \%L1 if a message is in plural form. The source 
+code should be as follows:
 
 \code
    int n = messages.count();
@@ -886,7 +847,7 @@ and not \%L1, i.e. the source code should should look like
    showMessage(qtTrId("xx_messages_saved", n));
 \endcode
 
-and the .ts file with the translations should look like:
+The .ts file with the translations should be as follows:
 
 \code
 <?xml version="1.0" encoding="UTF-8"?>
@@ -906,77 +867,71 @@ and the .ts file with the translations should look like:
 </TS>
 \endcode
 
-The second parameter “n” of qtTrId() does two things:
+The second parameter “n” of qtTrId():
 
 <ul>
 <li>
-It selects the correct translation for this value of “n”
-(note that if no translation exists and the engineering
-English fallback is used, the same message will be displayed
-for all values of “n” because there is only one
-version of the engineering English. I.e. in
-the above example “1 message(s) saved” would be shown
-if “n” is 1 and “2 message(s) saved” if “n” is 2).
+Selects the correct translation for this value of “n”. Note: If no translation exists 
+and the engineering English fallback is used, the same message is displayed for all values of 
+“n” because there is only one version of the engineering English. In other words, in the above 
+example “1 message(s) saved” is shown if “n” is 1 and “2 message(s) saved” if “n” is 
+2).
 </li>
 <li>
-It replaces the place holder \%Ln with the value of
-the number “n”, formatted in the locale specific way,
-possibly using localized numerals (\%n would also be
+Replaces the placeholder \%Ln with the value of
+the number “n”, formatted in the locale-specific way,
+possibly using localised numerals. \%n would also be
 replaced by the value of “n” but would not be formatted
-in a locale specific way).
+in a locale-specific way.
 </li>
 </ul>
 
-If \%L1 were used instead of \%Ln in the translation,
-the second parameter of qtTrId() would still select
-the correct translation for the value of “n” but would
-not replace \%L1, i.e. in this case the code 
+If \%L1 is used instead of \%Ln in the translation,
+the second parameter of qtTrId() still selects
+the correct translation for the value of “n” but does
+not replace \%L1. In this case the following code displays “\%L1 messages saved.”:
 
 \code
    showMessage(qtTrId("xx_messages_saved", 2));
 \endcode
 
-would display “\%L1 messages saved.”. If it is known 
-that the plural translations mistakenly use \%L1 instead
-of \%Ln, one can work around the issue by using an
-extra .arg() in the code like this:
+If you know that the plural translations mistakenly use \%L1 instead
+of \%Ln, you can work around the issue by using an
+extra .arg() in the code as follows:
 
 \code
    showMessage(qtTrId("xx_messages_saved", 2).arg(2));
 \endcode
 
 In this example, the “2” used as the second parameter
-of would select that correct plural form, i.e.
+ selects the correct plural form, which means that
 “\%L1 messages saved.” and the .arg(2) would replace
 the \%L1 with 2 so the final result would
 be “2 messages saved.” as desired. But as soon as the translation
 is fixed to use the correct \%Ln this code prints
-a warning
+a warning:
 
 \verbatim
    QString::arg: Argument missing: "2 messages saved." , 2 
 \endverbatim
 
-because the .arg(2) tries to replace a \%L1 which is not there.
+The reason for this is that the .arg(2) tries to replace a missing \%L1.
 
 \subsection  translationdatastorage  Translation data storage
 
-The convention for the path to store the compiled translation data (in
-.qm format) on the device is:
+The following path is used to store the compiled translation data (in
+.qm format) on the device:
 
 \code
    <top-directory>/<catalog-name>_<locale-code>.qm
 \endcode
 
-\c top-directory  can be anywhere on the device. \c locale-code  is
-something like \c en_US  for US-English, \c en_GB  for Britisch English,
-\c zh_CN  for Simplified Chinese, \c de_DE  for German in Germany, \c de_CH 
-for Swiss German, etc. <catalog-name> is usually the name of the
-application. If a translation for a more specific locale name like
-\c en_US  cannot be found, a less specific locale name like \c en  is
-tried. For example, if the application name is \c foo  and the locale
-name is \c en_US, the first one of the following files which exists
-is used:
+\c top-directory  can be anywhere on the device. \c locale-code  is, for example, \c en_US  for 
+US English, \c en_GB  for British English, \c zh_CN  for Simplified Chinese, \c de_DE  for German 
+in Germany, and \c de_CH for Swiss German. <catalog-name> is usually the name of the application. If a 
+translation for a more specific locale name such as \c en_US  cannot be found, a less specific 
+locale name such as \c en is tried. For example, if the application name is \c foo  and the locale
+name is \c en_US, the first existing file from the following list is used:
 
 \code
 <top-directory>/foo_en_US.qm
@@ -987,25 +942,24 @@ is used:
 <top-directory>/foo
 \endcode
 
-See also the documentation of
+For more information, see the documentation of
 <a href="http://doc.trolltech.com/4.5/qtranslator.html#load">QTranslator::load()</a>.
 
-The \c top-directory  used by default is \c /usr/share/l10n/meegotouch (This is
+The \c top-directory used by default is \c /usr/share/l10n/meegotouch. This is
 defined as \c M_TRANSLATION_DIR  in \c meegotouch_defines.prf which
 can be found in \c ./mkspecs/features/meegotouch_defines.prf` in the 
-libmeegotouch source code).
+libmeegotouch source code.
 
 `/usr/share/l10n/meegotouch` is also the default directory used by
 translation packages to store the .qm files. Applications can set
 additional search paths by using \c MLocale::setTranslationPaths() 
 and \c MLocale::addTranslationPath() . This supports the variability
-needed for over-the-air translation installation as well as for user
-defined translations.
+needed for over-the-air translation installation and user-defined translations.
 
 \subsection  translationdatapackaging  Translation data packaging
 
-The packaging of translations into debian packages is illustrated here
-using the demo application “widgetsgallery” as an example.
+The following example illustrates the packaging of translations into debian packages 
+using the demo application “widgetsgallery”:
 
 <table border="1">
   <caption>
@@ -1055,12 +1009,12 @@ using the demo application “widgetsgallery” as an example.
      </tr>
 </table>
 
-Every application needing translations should supply also a debian
+Every application that requires translations should also supply a debian
 package containing the “engineering English” translations.  The
 package name for the engineering English translations should end with
 -l10n-engineering-english as in the above example.  The package name
 “...-engineering-english” should make it clear that these are not real
-translations, instead they are completely auto-generated from the
+translations, but instead they are completely auto-generated from the
 source code.
 
 In the above example, the package
@@ -1071,65 +1025,59 @@ automatically generated from the source code using
 “lupdate”. “widgetsgallery.qm” is automatically generated from
 “widgetsgallery.ts” using “lrelease”. The make files in the
 application source code should contain support to do this
-automatically when building the application without extra effort (The
-current source code of widgetsgallery already gives an example how
-this can be done).
+automatically when building the application without extra effort. The
+current source code of widgetsgallery already illustrates how to do this.
 
-The “widgetsgallery.qm” file serves several purposes:
+The “widgetsgallery.qm” file:
 
 <ol>
 <li>
 
-It is used at runtime by the application to display engineering
-English instead of message ids to make testing the application easier
-while no real translations are available yet.
+Is used at runtime by the application to display engineering
+English instead of message IDs to facilitate application testing 
+when no real translations are available yet.
 
 </li>
 <li>
 
-It supplies fallback engineering English when real translations are
-available but incomplete. Of course this should never happen in the
-final product but it will happen during the development and testing
-and then this fallback engineering English is useful.
+Supplies fallback engineering English when real translations are available but incomplete. Even if 
+this should never occur with the final product, it can happen during development and testing. In 
+that case, it is useful to have fallback engineering English available.
 
 </li>
 <li>
 
-It gives us an easy way to extract a list of ids which are actually
-used in the source code. Using the tool “lconvert” one can easily
-extract all ids from a .qm file. If all meegotouch applications supply
-“...-l10n-engineering-english” packages, one can easily install all
-these packages (for example with “apt-get”) and then extract all ids
-which are actually used. Then these ids can be used for cross-checking
-with the ids used in the specifications and in the real translations.
+Allows you to easily extract a list of IDs which are actually used in the source code. You 
+can use the “lconvert” tool to extract all IDs from a .qm file. If all MeeGo Touch applications 
+supply “...-l10n-engineering-english” packages, you can easily install all the packages (for 
+example with “apt-get”) and extract all the IDs which are actually used. You can then 
+cross-check the IDs with the IDs used in the specifications and real translations.
 
 </li>
 </ol>
 
 “widgetsgallery” is only a test application used by the libmeegotouch
 developers for testing and demos. Therefore, the localisation
-department will not supply translations for “widgetsgallery”.  The
+department does not supply translations for “widgetsgallery”.  The
 libmeegotouch developers supply some demo translations for “widgetsgallery”
 to test their code and to make sure the system works.
 
-Only because of this, “widgetsgallery” has some “real” translation
-packages like “meegotouch-demos-widgetsgallery-l10n-zh-cn” containing
+For this reason, “widgetsgallery” has some “real” translation
+packages such as “meegotouch-demos-widgetsgallery-l10n-zh-cn” containing
 “/usr/share/l10n/meegotouch/widgetsgallery_zh_CN.qm” (see the table above).
 In that respect, “widgetsgallery” is an exception.
 
-For a “real” application, say “camera” which is intended to be shipped
+For a “real” application, such as “camera”, which is intended to be shipped
 to the customer, the “real” translation packages are supplied by the
-translation department, not by the developers. I.e. the developers
-will only supply “camera-l10n-engineering-english” and all the other
-packages “camera-l10n-ar”, “camera-l10n-zh-cn”, ..., will be supplied
-by the translation department.
+translator, not by the developers. The developers only supply 
+“camera-l10n-engineering-english” and the translator supplies all the other 
+packages, such as “camera-l10n-ar”, “camera-l10n-zh-cn”, and so on.
 
 As long as the real translations are still missing, the engineering
 English is displayed. As soon as the real translations are available
-and installed, they are used automatically. As can be seen in the
-above table, there is no file conflict between the engineering English
-packages and the real translations, they can both be installed at the
-same time without problems.
+and installed, they are used automatically. As the table above illustrates, there is no file 
+conflict between the engineering English packages and the real translations. They can both be 
+installed at the same time without problems.
 
 For the final product, the engineering English packages can be
 omitted. If it has been verified during the testing phase that the
@@ -1138,15 +1086,16 @@ needed anymore.
 
 \subsection  translationfordotdesktop  Translation for .desktop files
 
-The translation of .desktop files for MeeGo Touch UI differs a bit from the usual
-practise of Freedesktop.org. The rationale behind it is that we
+The translation of .desktop files for MeeGo Touch UI differs slightly from the usual
+practice of Freedesktop.org. The reason for this is that we
 have different localisation processes which make it impossible to
-modify the source of .desktop files during build time. To accommodate
-the special needs of our localisation processes, the .desktop file
-shall contain at least two extra (key, value) pairs:
+modify the source of .desktop files during the build time. Thus, the .desktop file must 
+contain at least two extra (key, value) pairs:
 
-- X-MeeGo-Logical-Id=&lt;logical name&gt;: The value for this key provides the logical name of the section name
-- X-MeeGo-Translation-Catalog=&lt;catalog name&gt;: The value for this key provides the catalog where the logical name exists
+- X-MeeGo-Logical-Id=&lt;logical name&gt;: The value for this key provides the logical name of the 
+section name
+- X-MeeGo-Translation-Catalog=&lt;catalog name&gt;: The value for this key provides the catalog 
+where the logical name exists
 
 For example:
 \code
@@ -1159,7 +1108,7 @@ X-MeeGo-Logical-Id=xx_setting_something
 X-MeeGo-Translation-Catalog=meegotouchsettings
 \endcode
 
-For the freedesktop specification of the .desktop files see
+For the freedesktop specification of the .desktop files, see
 
 <a href="http://standards.freedesktop.org/desktop-entry-spec/latest/">http://standards.freedesktop.org/desktop-entry-spec/latest/</a>
 
@@ -1176,74 +1125,64 @@ system can immediately use the new downloaded data.
 \subsection  localechange  Reacting to changes in the locale settings
 
 The current language setting is stored in the gconf key
-\c /meegotouch/i18n/language . From the command line, the current language can
-be queried using \c gconftool-2  like this:
+\c /meegotouch/i18n/language . You can use \c gconftool-2 to query the 
+current language from the command line:
 
 \code
     ~$ gconftool-2 -g /meegotouch/i18n/language
     ar
 \endcode
 
-In the above example, the current language is Arabic. Setting
-the current language from the command line can of course also be
-done with \c gconftool-2 :
+In the above example, the current language is Arabic. 
+
+You can also change the current language from the command line. For example, to set the current 
+language to simplified Chinese, you can use \c gconftool-2 :
 
 \code
     ~$ gconftool-2 -t string -s /meegotouch/i18n/language zh_CN
 \endcode
 
-The above command sets the current language to simplified Chinese.
-
-The preferred way to query the current language from a \c MApplication 
-works like this:
+To query the current language from a \c MApplication, use the following:
 
 \code
     MLocale currentLocale;
     QString language = currentLocale.name();
 \endcode
 
-\c MLocale currentLocale; gets a copy of the system default locale
-which is connected to the gconf settings and follows the gconf
+\c MLocale currentLocale; retrieves a copy of the system default locale
+that is connected to the gconf settings and follows the gconf
 settings.
 
-Alternatively it is possible to read the gconf settings directly:
+You can also read the gconf settings directly:
 
 \code
     MGConfItem languageItem("/meegotouch/i18n/language");
     QString language = languageItem.value().toString();
 \endcode
 
-This has the same effect as getting the current system locale and
-using \c currentLocale.name().
-
-Setting the current language permanently from a \c MApplication  works like
-this:
+To set the current language permanently from a \c MApplication, use the following:
 
 \code
     MGConfItem languageItem("/meegotouch/i18n/language");
     languageItem.set("zh_CN");
 \endcode
 
-One can also set a new current language temporarily from a \c MApplication 
-by doing:
+To set a new current language temporarily from a \c MApplication, use the following:
 
 \code
     MLocale newLocale("zh_CN");
     MLocale::setDefault(newLocale);
 \endcode
 
-This does not change the gconf settings and therefore this change will
-be lost as soon as one of the locale related gconf keys changes
-again. And it will be lost when the application restarts. Nevertheless
-this can be useful for temporary changes for testing and it is
-currently the only way to change the current language on systems
-without gconf like <a
+This does not change the gconf settings and, therefore, this change is lost as soon as one of the 
+locale related gconf keys changes again and when the application restarts. Nevertheless, this can be 
+useful for temporary changes for testing and it is currently the only way to change the current 
+language on systems without gconf, such as <a
 href="http://en.wikipedia.org/wiki/Microsoft_Windows">Windows</a> or
 <a href="http://en.wikipedia.org/wiki/Mac_OSX">Mac OS X</a>.
 
-If a the system locale changes, either because a locale related gconf
-key changed or because \c MLocale::setDefault()  has been called
-explicitly by the application, the following things happen:
+If a system locale changes, either because a locale-related gconf key changed or because 
+\c MLocale::setDefault()  has been called explicitly by the application:
 
 <ul>
 <li>
@@ -1251,37 +1190,35 @@ All translation catalogs are reloaded according to the new locale
 settings
 </li>
 <li>
-\c QEvent::LanguageChange  will be sent to the Application, if
-necessary. \c MWindow  will propagate a \c QEvent::LanguageChange  to all
+\c QEvent::LanguageChange  is sent to the Application, if
+necessary. \c MWindow  propagates a \c QEvent::LanguageChange  to all
 \c MWidgets  on the scene. A \c MWidget  which receives this event by
 calls its \c retranslateUi()  method.
 </li>
 <li>
-\c QEvent::ApplicationLayoutDirectionChange  will be sent to the
-Application, if necessary.  \c MWindow  will propagate a
+\c QEvent::ApplicationLayoutDirectionChange  is sent to the
+Application, if necessary.  \c MWindow  propagates a
 \c QEvent::LayoutDirectionChange  to all \c MWidgets  as appropriate to
 enable the widgets to change their layout on the fly.
 </li>
 <li>
-The signal \c settingsChanged()  will be emitted by the locale.
+The signal \c settingsChanged() is emitted by the locale.
 </li>
 <li>
-The signal \c localeSettingsChanged()  will be emitted by the
+The signal \c localeSettingsChanged() is emitted by the
 \c MApplication .
 </li>
 </ul>
 
-In most cases, an application doesn’t have to use the above signals
+In most cases, an application does not have to use the above signals
 \c settingsChanged()  and \c localeSettingsChanged()  because most
-stuff like reloading the translation catalogs already happens
+events such as reloading the translation catalogs already occur
 automatically. If \c retranslateUi()  methods are implemented
 for the widgets used in the application, the language of the
-user interface will already change automatically.
+user interface changes automatically.
 
-Optionally, an application can use these signals though, if it
-wants to do additional special things which do not happen
-automatically.
-For example:
+However, an application can use these signals optionally to perform special actions that do not occur 
+automatically. For example:
 
 \code
 main.cpp:
@@ -1297,7 +1234,7 @@ main.cpp:
     }
 \endcode
 
-where the FooHandleLocaleChange class looks like:
+where the FooHandleLocaleChange class is:
 
 \code
 foohandlelocalechange.h:
@@ -1339,7 +1276,7 @@ virtual method
 \endcode
 
 \c MWidgets  can reimplement this \c retranslateUi()  method to do whatever
-is necessary to retranslate itself, as in the following example:
+is necessary to retranslate itself. For example:
 
 \code
 foopage.h
@@ -1381,233 +1318,34 @@ locale settings change.
 <!-- reimplementing \c retranslateUi()  not necessary in many cases. -->
 
 \subsection  widgetmirroring  Widget mirroring and layout direction
-Widget mirroring is the automatic behaviour of putting the widgets in the reverse direction when the language is switched to Right-to-left languages (such as Arabic or Hebrew). In this direction, the widgets are put following the natural flow of text writing direction. Widget mirroring works automatically when the widgets are arranged using QGraphicsLayout or MLayout, with some exceptions with the specialist MLayout policies.
+Widget mirroring refers to automatically reversing the direction of the widgets when the language is 
+switched to right-to-left languages (such as Arabic or Hebrew). The widgets are arranged according 
+to the natural flow of written text. Widget mirroring works automatically when the widgets are 
+arranged using QGraphicsLayout or MLayout, with some exceptions with the specialist MLayout 
+policies.
 
-The layout direction will be automatically set to the correct value by MApplication when the language is changed. The current layout direction can be obtained from \c MApplication::layoutDirection() . Note that during the application lifetime, the direction may change if the user changes it from the global setting.
+The layout direction is automatically set to the correct value by MApplication when the language is 
+changed. The current layout direction can be obtained from \c MApplication::layoutDirection() . 
+Note: During the application lifetime, the user can change the direction from the global setting.
 
-If you are developing a widget in which it does not make sense for the layout to be reversed (for example, a number keypad), then use \c QGraphicsWidget::setLayoutDirection()  to override the layout direction.  If you need to paint your widget differently in right-to-left mode, simply call `qApp->layoutDirection()` and draw as appropriate.  If you are implementing a custom MAbstractLayoutPolicy, however, you should use the \c MLayout::layoutDirection() function instead so that the user can override it.
+If reversing the layout is not applicable for the widget that you are developing (for example, a 
+number keypad), use \c QGraphicsWidget::setLayoutDirection()  to override the layout direction.  If 
+you need to paint your widget differently in the right-to-left mode, simply call 
+`qApp->layoutDirection()` and draw it accordingly.  However, to implement a custom 
+MAbstractLayoutPolicy, use the \c MLayout::layoutDirection() function instead so that the user can 
+override it.
 
-In advanced situations you can handle the \c QEvent::ApplicationLayoutDirectionChange()  event directly in your widget's event handler.
-
-\section  currentstatusrtlsupportinmeegotouchwidgets  Current status of RTL support in MWidgets
-<table border="1">
-  <caption>
-  <big><b>
-    Current status of RTL support in MWidgets
-  </b></big>
-  </caption>
-    <tr>
-      <td><b>Widget</b></td>
-      <td><b>Works with RTL</b></td>
-      <td><b>Comments</b></td>
-    </tr>
-    <tr>
-      <td>MAnimatedIcon</td>
-      <td>OK</td>
-      <td>Nothing to do for RTL</td>
-    </tr>
-    <tr>
-      <td>MApplicationMenu</td>
-      <td>broken?</td>
-      <td>
-In widgetsgallery, click "Application Menu", then click "Application
-Menu" in the navigation bar. A menu with offering the names "Plato",
-"Twain", "Einstein", "Adams" is openened. Hit Control-D to change the
-layout direction, you see that the these names which were originally
-"almost" centred are aligned right in RTL mode. They should be aligned
-in a mirrored way, i.e. if they are a bit left of the centre in LTR
-mode, they should be a bit right of the centre in RTL mode.
-Is this a problem with MApplicationMenu or with MAction?
-      </td>
-    </tr>
-    <tr>
-      <td>MApplicationPage</td>
-      <td>OK</td>
-      <td>Nothing to do for RTL</td>
-    </tr>
-    <tr>
-      <td>MApplicationWindow</td>
-      <td>OK</td>
-      <td>Nothing to do for RTL</td>
-    </tr>
-    <tr>
-      <td>MButton</td>
-      <td>OK</td>
-      <td>
-But the switches in the switchpage of widgetsgallery (which are
-MButtons) do not reverse the alignment of their ON/OFF texts.
-Problem in MButton or somewhere else?
-      </td>
-    </tr>
-    <tr>
-      <td>MButtonGroup</td>
-      <td>OK</td>
-      <td>Nothing to do for RTL</td>
-    </tr>
-    <tr>
-      <td>MComboBox</td>
-      <td>OK</td>
-      <td></td>
-    </tr>
-    <tr>
-      <td>MContainer</td>
-      <td>OK</td>
-      <td>Nothing to do for RTL</td>
-    </tr>
-    <tr>
-      <td>MDialog</td>
-      <td>OK</td>
-      <td></td>
-    </tr>
-    <tr>
-      <td>MDockWidget</td>
-      <td>OK</td>
-      <td>Nothing to do for RTL</td>
-    </tr>
-    <tr>
-      <td>MEscapeButtonPanel</td>
-      <td>OK</td>
-      <td>Nothing to do for RTL</td>
-    </tr>
-    <tr>
-      <td>MGrid</td>
-      <td>broken</td>
-      <td>
-
-There seems to be a grid with gray squares in the background and blue
-buttons in the foreground in the widgetsgallery grid page. In LTR
-mode, the gray squares align with the blue buttons, i.e. on top of
-each gray square is a blue button. In LTR mode, the two arrays
-are shifted against each other. This doesn't look right. 
-
-      </td>
-    </tr>
-    <tr>
-      <td>MHomeButtonPanel</td>
-      <td>OK</td>
-      <td>Nothing to do for RTL</td>
-    </tr>
-    <tr>
-      <td>MImage</td>
-      <td>OK</td>
-      <td>Nothing to do for RTL</td>
-    </tr>
-    <tr>
-      <td>MInfoBanner</td>
-      <td>broken</td>
-      <td>
-Always slides in from the left side, see "Dialogs and Notifications"
-page in widgetsgallery.
-      </td>
-    </tr>
-    <tr>
-      <td>MLabel</td>
-      <td>OK</td>
-      <td>
-It did not change alignment on the fly until recently but this is
-fixed now, see <a
-href="https://projects.maemo.org/bugzilla/show_bug.cgi?id=144377">NB#144377</a>
-      </td>
-    </tr>
-    <tr>
-      <td>MMessageBox</td>
-      <td>OK</td>
-      <td></td>
-    </tr>
-    <tr>
-      <td>MModalSceneWindow</td>
-      <td>OK</td>
-      <td>Nothing to do for RTL</td>
-    </tr>
-    <tr>
-      <td>MNavigationBar</td>
-      <td>broken</td>
-      <td>Icon in the navigation bar is always on the left side</td>
-    </tr>
-    <tr>
-      <td>MObjectMenu</td>
-      <td>probably OK</td>
-      <td>Where is this used?</td>
-    </tr>
-    <tr>
-      <td>MPannableViewport</td>
-      <td>OK</td>
-      <td>Position indicator correctly changes side</td>
-    </tr>
-    <tr>
-      <td>MPannableWidget</td>
-      <td>OK</td>
-      <td>Nothing to do for RTL</td>
-    </tr>
-    <tr>
-      <td>MPopupList</td>
-      <td>OK</td>
-      <td></td>
-    </tr>
-    <tr>
-      <td>MProgressIndicator</td>
-      <td>OK</td>
-      <td></td>
-    </tr>
-    <tr>
-      <td>MPositionIndicator</td>
-      <td>broken</td>
-      <td>
-Is always on the right side. Can be seen on the start page
-of Widgetsgallery.
-      </td>
-    </tr>
-    <tr>
-      <td>MSeekBar</td>
-      <td>broken</td>
-      <td>
-slides correctly from the right in RTL mode but the black
-area showing the "already" downloaded stuff is only visible in LTR mode.
-      </td>
-    </tr>
-    <tr>
-      <td>MSeparator</td>
-      <td>OK</td>
-      <td>Nothing to do for RTL</td>
-    </tr>
-    <tr>
-      <td>MSlider</td>
-      <td>OK</td>
-      <td></td>
-    </tr>
-    <tr>
-      <td>MSlideShow</td>
-      <td>OK</td>
-      <td>Nothing to do for RTL</td>
-    </tr>
-    <tr>
-      <td>MTextEdit</td>
-      <td>OK</td>
-      <td>
-<a href="https://projects.maemo.org/bugzilla/show_bug.cgi?id=104397">NB#104397</a>
-is very obvious here, but this is not the fault of MTextEdit.
-      </td>
-    </tr>
-    <tr>
-      <td>MToolBar</td>
-      <td>OK</td>
-      <td></td>
-    </tr>
-    <tr>
-      <td>MWindow</td>
-      <td>OK</td>
-      <td>Nothing to do for RTL</td>
-    </tr>
-</table>
+In advanced situations you can handle the \c QEvent::ApplicationLayoutDirectionChange()  event 
+directly in your widget's event handler.
 
-\section  charsetconversion  Charset Conversions
+\section  charsetconversion  Charset conversions
 
 The MeeGo Touch UI Framework uses the Qt character set conversion
 mechanisms directly. Therefore, developers can follow the Qt
 documentation to find out how to use the character set conversion
 functionalities.
 
-\section  generalchecklist  General Checklist
+\section  generalchecklist  General checklist
 
 \subsection General General
 \subsubsection  fontsize  Fonts size
@@ -1617,8 +1355,8 @@ English text. This may impact the layout design.
 
 \subsubsection Plural Plural
 
-Some languages use plural and some do not. Some other languages use
-more than one form of plurals.
+Some languages use plural and some do not. There are also languages that use more than one plural 
+form.
 
 \subsubsection Sorting Sorting
 
@@ -1628,11 +1366,10 @@ MeeGo Touch UI collator to sort the strings.
 \subsubsection  wordboundaries  Word boundaries
 
 In some languages there is no space between words. In most cases the
-line wrapping will work and the system will break the sentence into
-smaller chunks. If it fails, translators shall use whitespace to force
-word boundaries.
+line wrapping works and the system breaks the sentence into smaller chunks. If it fails, translators 
+can use whitespace to force word boundaries.
 
-\subsubsection  wordorder  Word order, variables
+\subsubsection  wordorder  Word order and variables
 
 When a sentence contains several variables, the order of the words in
 other languages may be different. Use QString place marker to define
@@ -1644,12 +1381,11 @@ the order of the variables.
                    .arg(packageName).arg(repository).arg(size);
 \endcode
 
-When translating, translators shall also keep the place markers and
-put them in the correct places.
+When translating, translators must also keep the place markers and put them in the correct places.
 
 Note how %L3 was used for the size parameter which is a number.  Using
-%L3 instead of just %3 has the advantage that localized numerals may
-be used. For example if the language of the locale is Arabic and the
+%L3 instead of just %3 has the advantage that localised numerals may
+be used. For example, if the language of the locale is Arabic and the
 numeric settings of the locale do not override it, %L3 causes
 Arabic-Indic numerals to be used. If the translator wants to disable
 this behaviour for this particular message and force usage of Arabic
@@ -1670,17 +1406,16 @@ MeeGo Touch UI collation system instead.
 
 \subsubsection  avoidhardcoding  Avoid hardcoding
 
-Some data such as graphics, icons, sounds, etc sometimes need to be
-correctly loaded dependent on the regional setting. In this case,
-never hard code the data directory, instead use the regional setting
+Some data types, such as graphics, icons, and sounds, sometimes need to be loaded according to  
+the regional setting. In these cases, never hard code the data directory, instead use the regional setting
 information to build the string to point to the correct directory
 containing the data.
 
 \subsubsection  neverconcatstrings  Never concatenate strings
 
-If you need to construct a string involving variables, never concate
-the UI strings. The string order is never guaranteed to the same in
-all languages. Never do this:
+If you need to construct a string involving variables, never concatenate
+the UI strings. It can never be guaranteed that the string order is the same in
+all languages. Do not use the following:
 
 \code
    QString message = "You have " + numMessages + " messages";
@@ -1694,86 +1429,75 @@ Instead use a variable when constructing the string:
 
 \subsubsection  dataformat  Data formatting
 
-Date, time, numbers, name, address, currency data are required to be
-formatted before displayed on the screen. Never display unformatted
-data as it breaks the data presentation consistency. Formatted data
-always use the correct presentation according to the regional
-setting. Special case for address data, it shall be formatted
-according to the customary of the country which stated in the address.
+Date, time, numbers, name, address, and currency data require formatting before they can be 
+displayed on the screen. Never display unformatted data as it breaks the data presentation 
+consistency. The data format should always follow the regional setting. Address data is 
+an exception because it must be formatted according to the conventions of the country stated in the 
+address.
 
 \subsection  uidesign  UI Designers
 \subsubsection Abbreviations Abbreviations
 
-In general, avoid using abbreviations as part of the UI string. The
-abbreviations ofter are misleading and confuse the
-translators. Instead, allow for more text expansion
+In general, avoid using abbreviations as part of the UI string. Abbreviations are often misleading 
+and confuse translators. Instead, increase the available space for the text.
 
 \subsubsection Emphasis Emphasis
 
-Never use casing when indicating functionality or emphasis. Some
-languages do not observe distinction between lowercase and
-uppercase. The translator may have difficulties to find out how to
-emphasise the string when the original English string uses uppercase for
-the emphasis.
+Never use case to indicate functionality or emphasis. Some languages do not observe a distinction 
+between lower-case and upper-case letters. Using upper case to indicate emphasis in the original 
+English string may cause difficulties when translating the string into other languages.
 
-Other methods such as using certain typeface to show emphasis also
-discouraged as not all writing systems support them.
+You should also avoid using certain typeface and other similar methods to show emphasis because they 
+are not supported by all writing systems.
 
-\subsubsection  characterrepertoire  Character repertoire
+\subsubsection  characterrepertoire  Character range
 
-Never use characters outside the ASCII repertoire as part of original
+Never use characters outside the ASCII range as part of original
 English strings. The font needed to display the character may not
 available in the device variant used for other languages.
 
 \subsubsection Compounds Compounds
 
-Some languages create words by combining a few words together. The
+Some languages create words by combining several words together. The
 resulting words are often longer than the original English
 string. Make sure that the UI allows the text expansion in these
 languages.
 
 \subsubsection Digits Digits
 
-Some languages use their own digits (term: national digits) to show
-the numbers. Allow the usage of national digits in some cases (for
-example when displaying general strings containing numbers) and force
-the UI to only use the Latin digits in other cases (for example when
+Some languages use their own digits (term: national digits) for numbers. Allow the usage of national 
+digits in some cases (for example, when displaying general strings containing numbers) and force
+the UI to only use the Latin digits in other cases (for example, when
 displaying IP addresses).
 
 \subsubsection  writingdirection  Writing direction
 
-Some languages use different writing direction than the Latin based
-languages. The UI presentation generally follows the natural flow of
-the writing direction. Therefore, the widget layout and composition is
-mirrored when the device language is set to the languages which use
-the right-to-left writing direction. The mirroring is done
-automatically by the MeeGo Touch UI Framework. If the automatic mirroring is
-not sufficient then consult the developers to support different layout
-for right-to-left direction.
+Some languages use a different writing direction than Latin-based languages. The UI presentation 
+generally follows the natural flow of the writing direction. Therefore, the widget layout and 
+composition is mirrored when a language written from right to left is set as the device language. 
+The mirroring is performed automatically  by the MeeGo Touch UI Framework. 
 
-MeeGo Touch UI Framework currently only supports left-to-right and
-right-to-left writing directions.
+MeeGo Touch UI Framework currently only supports left-to-right and right-to-left writing directions.
 
 \subsubsection Gender Gender
 
-Some languages use gender when referring to objects or words. 
+Some languages distinguish between grammatical genders when referring to nouns. 
 
 \subsubsection  colorandgraphics  Colour and graphics
 
 Colours often have different meanings and connotations in different
-cultures. In Western culture, red is often used to indicate stop or
+cultures. In the Western culture, red is often used to indicate stop or
 danger. In China, red is symbolic of celebration, luck and
-prosperity. White signifies purity, virginity, or death. In Western
+prosperity. White signifies purity, virginity, or death. In the Western
 culture it is the colour worn at weddings. In parts of Japan and China
-the colour worn at funerals.
+white is worn in funerals.
 
-Never embed text and/or numbers in graphics, otherwise the graphics
-need to be translated and it may be difficult and expensive.
+Never embed text and/or numbers in graphics. Translating graphics may be difficult and expensive.
 
-Some icons or drawings considered offensive in some cultures. 
+Some icons or drawings are considered offensive in some cultures. 
 
-\subsubsection  slitstrings  Split strings when containing date and time format
+\subsubsection  slitstrings  Split strings that contain date and time format
 
-See section "Translation involving date/time format" above.
+See section "Date and time" above.
 
 */
diff --git a/doc/src/input_feedback.dox b/doc/src/input_feedback.dox
index e5154b86..eddc84db 100644
--- a/doc/src/input_feedback.dox
+++ b/doc/src/input_feedback.dox
@@ -2,44 +2,44 @@
 
 \section input_feedback_support Input feedback support for MeeGo Touch applications
 
-MeeGo Touch provides an easy way to integrate immediate feedback into graphical applications. The concept is based on the Qt's signal/slot architecture and the standard theme principles of Linux systems and it is therefore easy to understand and deploy.
+MeeGo Touch provides an easy way to integrate immediate feedback into graphical applications. The concept is based on the Qt's signal/slot architecture and the standard theme principles of Linux systems, and it is therefore easy to understand and deploy.
 
-A mobile device can support several means for feedback, for example audio speaker, vibra or piezo actuators. Input feedback helps the user to use the graphical controls on the touch screen by providing feedback which is similar to physical buttons. MeeGo Touch offers low latency input feedback which is important for the usability of the product.
+A mobile device can support several means for feedback, for example, audio speaker, vibra or piezo actuators. Input feedback facilitates the use of graphical controls on the touch screen by providing feedback which is similar to physical buttons. MeeGo Touch offers low latency input feedback which is important for the usability of the product.
 
 \subsection technical_background Short technical background
 
-The feedbacks are identified by name. For instance, if a user touches a button on the screen, "press" feedback is played or if a selected check box is pressed, "press-off" feedback is played. These feedbacks are played by a daemon (meegofeedbackd) that is invisible for the developers. Different types of feedback methods can be provided by different hardwares:
+The feedbacks are identified by name. For instance, if a user touches a button on the screen, "press" feedback is played or if a selected check box is pressed, "press-off" feedback is played. The feedbacks are played by a daemon (meegofeedbackd) that is invisible for the developers. Different types of feedback methods can be provided by different hardware:
 
 - Vibra: Based on Immersion TouchSense&reg;
 - Audio: Based on PulseAudio
 
-MFeedback class provides an interface to send playback requests from a MeeGo Touch application to the feedback daemon. In practice, when a feedback related signal is emitted, it should be translated into a feedback name and sent to the feedback daemon via MFeedback class. The MFeedback class only forwards the feedback name to the feedback daemon, it does not know anything about the source of the signal which triggered that event and the feedback name is not validated at MeeGo Touch level. The feedback daemon receives the feedback name, validates it in the context of the current theme and the application name and plays the corresponding vibra/audio feedback if there is any. If multiple feedbacks (e.g audio and vibra) are available for the same name, they are played simultaneously.
+MFeedback class provides an interface to send playback requests from a MeeGo Touch application to the feedback daemon. In practice, when a feedback-related signal is emitted, it should be translated into a feedback name and sent to the feedback daemon through the MFeedback class. The MFeedback class only forwards the feedback name to the feedback daemon, it does not know anything about the source of the signal which triggered the event and the feedback name is not validated at MeeGo Touch level. The feedback daemon receives the feedback name, validates it in the context of the current theme and the application name and plays the corresponding vibra/audio feedback if there is any. If multiple feedbacks (for example, audio and vibra) are available for the same name, they are played simultaneously.
 
 \subsection feedbacks_in_themes Feedbacks in themes
 
-Read the feedbacks part of \ref theme_structure "theme directory structure" documentation to see how the feedback files are located in themes.
+For more information on the location of the feedback files in themes, see section Feedbacks in \ref theme_structure Theme directory structure.
 
 Typically, a feedback directory can contain two files: vibra.ivt and audio.wav.
 
 Some principles are followed in the theme logic:
-- When an event happens (e.g. pressing an MButton), both a vibra and an audio feedback are played at the same time if available.
-- If a feedback directory does not contain any file for a hardware (e.g. vibra.ivt), a fallback mechanism tries to find an other effect going back on the theme inheritance tree.
-- Using a non-existing name (e.g. "press-loud") triggers fallback mechanism to look for a generic feedback name before the first (and only the first) dash (e.g "press-loud-something" -> "press").
-- A zero sized sample file means no feedback, the fallback mechanism stops at such point.
+- When an event happens (for example, pressing an MButton), both a vibra and an audio feedback are played at the same time if available.
+- If a feedback directory does not contain any file for a hardware (for example, vibra.ivt), a fallback mechanism tries to find another effect going back on the theme inheritance tree.
+- Using a non-existing name (for example, "press-loud") triggers the fallback mechanism to look for a generic feedback name before the first (and only the first) dash (for example, "press-loud-something" -> "press").
+- A zero-sized sample file means no feedback, the fallback mechanism stops at that point.
 
-The feedbacks can be played on three different volume levels. This is a global setting of the feedback daemon, but the feedbacks should be prepared for. The Pulseaudio (audio) backend of the daemon sets the appropriate playback volume from a config file so nothing needs to be done in Pulseaudio case. The vibra backend checks the vibra.ivt for three timeline effects named "low", "medium" and "high" referring to low, medium and high volume levels. If there are no correctly named timeline effects in the effect file, the first effect is used (its type does not matter in this case).
+The feedbacks can be played on three different volume levels. This is a global setting of the feedback daemon, but the feedbacks should be prepared for. The PulseAudio (audio) backend of the daemon sets the appropriate playback volume from a config file so nothing needs to be done in PulseAudio case. The vibra backend checks the vibra.ivt for three timeline effects named "low", "medium" and "high", referring to low, medium and high volume levels. If there are no correctly named timeline effects in the effect file, the first effect is used (its type does not matter in this case).
 
-\subsection stylesheets Stylesheets
+\subsection stylesheets Style sheets
 
-Recommended to read the \ref styling "styling" part of the MeeGo Touch documentation before this section, because only the feedback specific syntax is described here.
+This section only describes the feedback-specific syntax. Thus, it is recommended that you read first the \ref styling Styling section of the MeeGo Touch documentation.
 
-A css file is associated with an application to describe the style of the widgets. For an application named "example" and a theme named "base", it is located in /usr/share/themes/base/meegotouch/example/style/example.css. The widgets in the applications can be styled on class (means e.g. every button in an application) or object/instance level (means one specific button in the application). Here is a minimal explanation about this concept for readers without deeper developer knowledge:
+A CSS file is associated with an application to describe the style of the widgets. For an application named "example" and a theme named "base", it is located in /usr/share/themes/base/meegotouch/example/style/example.css. The widgets in the applications can be styled at class-level (for example, for every button in an application) or at object/instance level (for one specific button in the application). The following is a brief overview of style sheets:
 
-- The widgets in an application are instances of their class definitions. E.g. Buttons are instances of MButton classes.
-- To distinguish two instances of the same class (e.g an Ok and Cancel button on the screen), the different instances can be named. This name is not visible on the screen and does not have any predefined format, but gives the potential to differentiate the instances (e.g. buttons) for styling.
-- As a natural demand, there are use cases when the instances of different classes should be themed with the same rules. E.g. Buttons and text input fields (MTextEdit) have a common style property on a particular window, for instance text color. In these cases, the instances can be named with the same name and style with a simple rule referring to the name, but not to the class type.
+- The widgets in an application are instances of their class definitions. For example, buttons are instances of MButton classes.
+- To distinguish two instances of the same class (such as OK and Cancel buttons on the screen), the different instances can be named. This name is not visible on the screen and does not have any predefined format, but it allows the differentiation of the instances (such as buttons) for styling.
+- There are naturally use cases when the instances of different classes should be themed with the same rules. For example, buttons and text input fields (MTextEdit) have a common style property in a particular window, such as text colour. In these cases, the instances can be named with the same name and style with a simple rule referring to the name, but not to the class type.
 
-Let's see some real-life examples for the principles above. If a style is specific to every instance of a class then it should be written in the following form:
+The following real-life examples illustrate the principles above. If a style is specific to every instance of a class, it must be written as follows:
 
 \code
 MButtonStyle {
@@ -60,7 +60,7 @@ If multiple instances of several classes (MButton, MTextEdit) are named with the
 }
 \endcode
 
-Specifying a feedback "huge-feedback" for the "press" event of an MButton widget instance with the object name "SignInButton":
+In the following example, "huge-feedback" is specified for the "press" event of an MButton widget instance with the object name "SignInButton":
 
 \code
 MButtonStyle#SignInButton {
@@ -72,15 +72,15 @@ As shown above, the styling rules are written between the curly brackets.
 
 \section mfeedback MFeedback
 
-MFeedback class is a thin convenience class to have input feedbacks very easily.
+MFeedback class is a thin convenience class used to easily play input feedbacks.
 
-\subsection mfeedback_instance Using an MFeedback instance to play a "press" feedback:
+\subsection mfeedback_instance Playing a "press" feedback with MFeedback instance 
 
 \code
 MFeedback* feedback = new MFeedback("press");
 \endcode
 
-Play the input feedback by hand:
+Play the input feedback manually:
 
 \code
 feedback->play();
@@ -92,15 +92,15 @@ Connect a signal to the feedback:
 connect(button, SIGNAL(pressed()), feedback, SLOT(play()));
 \endcode
 
-\subsection mfeedback_static Using static MFeedback::play(const QString&) to play a "press" feedback:
+\subsection mfeedback_static Playing a "press" feedback with static MFeedback::play(const QString&) 
 
 \code
 MFeedback::play("press");
 \endcode
 
-Behind the scenes the feedback event is forwarded to the feedback daemon and the audio/vibra feedback gets played as soon as possible.
+Behind the scenes the feedback event is forwarded to the feedback daemon and the audio/vibra feedback is played as soon as possible.
 
-\subsection minimal_application Minimal application that plays "press" feedback without using any widgets
+\subsection minimal_application Creating a minimal "press" feedback application without widgets
 
 The following application simply plays a feedback called "press".
 
@@ -131,9 +131,9 @@ int main(int argc, char* argv[])
 }
 \endcode
 
-\subsection simple_application Simple application that uses MButton widget to play feedbacks
+\subsection simple_application Creating a simple feedback application with MButton widget 
 
-The following application creates a window and places a button (MButton) in that window. The default press and release feedbacks are used automatically. Feedback named "press" is played when button is pressed and feedback named "release" is played when the button is released. These "press" and "release" feedback files are loaded from the current theme.
+The following application creates a window and places a button (MButton) in the window. The default press and release feedbacks are used automatically. Feedback named "press" is played when button is pressed and feedback named "release" is played when the button is released. These "press" and "release" feedback files are loaded from the current theme.
 
 app.pro:
 
@@ -174,7 +174,7 @@ int main(int argc, char* argv[])
 
 \subsection advanced_example Advanced example with plain Qt widgets
 
-The following application creates a window and places a "Hello world!" button in the window. The default input feedback support will be switched off by forcing the usage of the motif style, but the press feedback is connected to the pressed signal of the button manually. If any argument is passed to the application the feedback is not connected to the signal. 
+The following application creates a window and places a "Hello world!" button in the window. The default input feedback support is switched off by forcing the usage of the motif style, but the press feedback is connected to the pressed signal of the button manually. If any argument is passed to the application, the feedback is not connected to the signal. 
 
 app.pro:
 
@@ -224,14 +224,14 @@ int main(int argc, char* argv[])
 
 \section feedback_use_case1 Styling use case 1: Override a default feedback for an application
 
-Let's say that an application name is "app" and we want to change the "press" feedback to an application specific custom feedback regardless of the selected theme. To achieve this the following should be done:
+In this use case the application name is "app". To change the "press" feedback to an application-specific custom feedback (regardless of the selected theme):
 
-- The new feedback files should be placed in the base theme directory structure because every theme is derived from this theme. This leads to the fact that the custom feedback will be the same regardless of the selected theme. This is true because an application specific feedback always overrides the general theme specific feedback.
-- The base theme can be extended/overriden in the application specific part. Thus the correct place for the new files is at /usr/share/themes/base/meegotouch/app/feedbacks/press
+- The new feedback files must placed in the base theme directory structure because every theme is derived from this theme. Thus, the custom feedback is the same regardless of the selected theme. This is true because an application-specific feedback always overrides the general theme-specific feedback.
+- The base theme can be extended/overriden in the application-specific part. Thus, the correct location for the new files is: /usr/share/themes/base/meegotouch/app/feedbacks/press
 
 \section feedback_use_case2 Styling use case 2: Use an MButton widget and override the default feedback
 
-The application created in this section places a normal MButton named "NormalButton" in a window and the style sheet overrides the default "press" feedback of the press feedback into "press-on" feedback. The app.css file should be placed in the usr/share/themes/base/meegotouch/app/style directory.
+This use case creates an application which places a normal MButton named "NormalButton" in a window and the style sheet overrides the default "press" feedback of the press feedback with the "press-on" feedback. The app.css file must be placed in the usr/share/themes/base/meegotouch/app/style directory.
 
 app.css:
 
diff --git a/doc/src/installation.dox b/doc/src/installation.dox
index 74ab4de5..f346badb 100644
--- a/doc/src/installation.dox
+++ b/doc/src/installation.dox
@@ -1,6 +1,6 @@
 /*! \page installation Installing MeeGo Touch
 
-\note You may be able to use one of the ready made packages for your platform.
+\note You may be able to use one of the ready-made packages for your platform.
 
 \section commonreqs MeeGo Touch common requirements
 
@@ -10,8 +10,9 @@ MeeGo Touch requires <a href="http://qt.nokia.com">Qt version 4.7</a> or later.
 Qt 4.7, you can <a href="http://qt.nokia.com/downloads">download the SDK for free</a> for a number of
 systems.
 
-If you have installed the Qt SDK to your home directory in Linux, you must set the following
-environment variables before building the MeeGo Touch modules by running the commands:
+If you have installed the Qt SDK to your home directory in Linux, you must set the required
+environment variables before building the MeeGo Touch modules. 
+To set the variables, run the following commands:
 
 <pre>
 export QTDIR=/home/[your home directory]/qtsdk-2010.01/qt/
@@ -20,12 +21,12 @@ export PATH=${QTDIR}/bin:${PATH}
 
 \subsection MeeGo Touch Theme
 
-A theme is required to be installed for MeeGo Touch applications to function. The MeeGo Touch
-development theme is freely available for download in the <a href="http://meego.gitorious.org/meegotouch/meegotouch-theme">meegotouch-theme module</a>
+You need to install a theme for MeeGo Touch applications to function. The MeeGo Touch
+development theme is freely available for downloading in the <a href="http://meego.gitorious.org/meegotouch/meegotouch-theme">meegotouch-theme module</a>
 of the code repository. On Mac OS X and Windows, the theme is already by default embedded into the
-MeeGo Touch distribution file .
+MeeGo Touch distribution file.
 
-On Linux, the following commands will build and install the default theme from the source module:
+On Linux, use the following commands to build and install the default theme from the source module:
 <pre>
 cd meegotouch-theme
 qmake
@@ -34,14 +35,14 @@ sudo make install
 
 \section linuxreqs MeeGo Touch on Linux build requirements
 
-MeeGo Touch will build on a Linux desktop machine using only the tools and development
+MeeGo Touch builds on a Linux desktop machine using only the tools and development
 packages provided by a typical Linux distribution:
 
  - Build essentials, such as libc, gcc, g++ and make
  - Mesa OpenGL development headers (or vendor specific equivalent)
  - X11 development headers, specifically the X damage extension
 
-Taking any recent version of Ubuntu Linux as an example, all the necessary packages can be installed with the following command:
+In all recent versions of Ubuntu Linux, all the necessary packages can be installed with the following command:
 
 <pre>
 sudo apt-get install build-essential libgl1-mesa-dev libglu1-mesa-dev libxdamage-dev
@@ -49,32 +50,35 @@ sudo apt-get install build-essential libgl1-mesa-dev libglu1-mesa-dev libxdamage
 
 \section linux Building MeeGo Touch on Linux
 
-1. Get the source code for libmeegotouch from a source package or straight from the
+1. Get the source code for libmeegotouch from a source package or directly from the
 <a href="http://meego.gitorious.org/meegotouch/libmeegotouch>code repository</a>.
 
-2. To configure the library for your machine, run the ./configure script in the source directory.
-By default libmeegotouch will be installed under the /usr/local/ directory, but this can be
-changed by giving the configure script the -prefix option.  Type ./configure -help to get a list
-of all available options.
+2. To configure the library for your computer, run the ./configure script in the source directory:
 
 <pre>
 cd libmeegotouch
 ./configure
 </pre>
 
-To build the library, tools and demos, type:
+By default, libmeegotouch is installed under the /usr/local/ directory, but you can change this
+by giving the configure script the -prefix option.  To get a list of all available options, run the 
+following command:
+
+<pre>./configure -help</pre>
+
+3. To build the library, tools and demos, use the following command:
 
 <pre>
 make
 </pre>
 
-If you want to install the tools and libraries to your system, type:
+4. To install the tools and libraries to your system, use the following command:
 
 <pre>
 sudo make install
 </pre>
 
-Note that the demos and examples can be run from inside the build directory without installing the
+Note: You can run the demos and examples inside the build directory without installing the
 library to the system. Simply append the build's <i>lib</i> directory to the LD_LIBRARY_PATH
 environment variable before running the program:
 
diff --git a/doc/src/introduction.dox b/doc/src/introduction.dox
index 280c2b8a..c60ca506 100644
--- a/doc/src/introduction.dox
+++ b/doc/src/introduction.dox
@@ -4,53 +4,54 @@
 
 MeeGo Touch is a cross-platform application and UI framework library built on top of
 <a href="http://qt.nokia.com">Qt</a>. The framework library makes use of the very
-latest Qt features to implement a specific UI style primarily targeting touch screen
+latest Qt features to implement a specific UI style which is primarily intended for touch screen
 devices.
 
-Using MeeGo Touch makes it easy to implement good looking, fully finger optimized applications
-that automatically take advantage of multitouch, device sensors, animations and transitions
+Using MeeGo Touch makes it easy to implement good-looking, fully finger-optimised applications
+that automatically take advantage of multipoint touch, device sensors, animations and transitions
 to create an iconic user experience on a range of platforms from handhelds to the desktop.
 
-\section style The MeeGo Touch style
+\section style MeeGo Touch style
 
 The core of the MeeGo Touch style can be summarised as "direct manipulation of content". This places
-the focus of the applications squarely on the users' content, be that created by himself such as
-photos taken with the device itself, or content that is coming from the network. In a typical MeeGo Touch
-application the content therefore occupies the majority of the view, with the rest of the UI
-elements being de-emphasized.
+the focus of the applications squarely on the content that the users either create themselves (such 
+as photos taken with the device itself) or is retrieved from the network. Therefore, in a typical MeeGo 
+Touch application, the content occupies the major part of the view, and the rest of the UI elements are 
+de-emphasised.
 
-The MeeGo Touch style discards many well known concepts from the desktop world such as file
+The MeeGo Touch style discards many well-known concepts from the desktop world such as file
 selection dialogs, scrollbars, tabs and so on. Due to the focus on touch, the user experience is
-highly tacticle with panning, flicking, dragging and pinching being common operations on wide
-variety of content. Instead of applications consisting of multiple windows as on a desktop,
-a MeeGo Touch application is typically divided into views and transitions between these.
-
-Core to the concept of the MeeGo Touch style is the application canvas, a 2D pannable virtual area that
-extends beyond the physical borders of the screen. The use of a canvas as the foundation on which
-everything else is built breaks the limitations associated with traditional static UIs, be they
-Qt based or created with some other framework. For instance, any object on the canvas can be arbitrarily
-transformed, including rotated, scaled or perspective adjusted. Every object on the scene exposes a
-set of properties that can be animated, such as its current position, size, and opacity. Objects
-on the scene are also free to overlap and can be grouped into layers. All of this allows for the creation
-of highly fluid user interfaces where objects smoothly transition in and out of view, or where certain
-objects can detach from the rest of UI and stay pinned on the screen while all other content is replaced.
-
-MeeGo Touch presents a programming interface that will seem familiar to developers with other
-UI frameworks such as Qt, most of the time it is therefore not necessary to understand the workings
-of the underlying canvas itself. However, if the developer so chooses he has the possibility of
-going beyond the ready made components provided in the MeeGo Touch style and taking direct advantage of
-the canvas in his application. In such cases MeeGo Touch also offers a set of lower level enablers to
-make his application themable and stylable for the scene.
+highly tactile with panning, flicking, dragging and pinching being common operations on a wide
+variety of content. A MeeGo Touch application is typically divided into views and transitions 
+between the views, instead of multiple windows as on a desktop.
+
+The application canvas is the core of the MeeGo Touch style. It is a 2D pannable virtual area that
+extends beyond the physical borders of the screen. Using the canvas as the foundation on which
+everything else is built overcomes the limitations associated with traditional static UIs, be they
+Qt-based or created with some other framework. For instance, any object on the canvas can be arbitrarily
+transformed, including rotated, scaled or perspective-adjusted. Every object on the canvas exposes a
+set of properties, such as the current position, size, and opacity, that can be 
+animated. Objects on the canvas can also freely overlap and be grouped into layers. These features 
+enable highly fluid user interfaces where objects smoothly transition in and out of view, or where 
+certain objects can detach from the rest of UI and stay pinned on the screen while all other content 
+is replaced.
+
+MeeGo Touch presents a programming interface that is similar to other UI frameworks such as Qt. Most 
+of the time it is, therefore, not necessary to understand the workings of the underlying canvas 
+itself. However, developers can also go beyond the ready-made components provided by the MeeGo 
+Touch style and take direct advantage of the canvas in their applications. In such cases MeeGo 
+Touch also offers a set of lower-level enablers to make an application themable and stylable for the 
+scene.
 
 \section qt Relationship with Qt
 
 <a href="http://qt.nokia.com">Qt</a> by itself is already a mature cross-platform framework,
-providing a full set of traditional widgets that have been used in a number of successfull
-applications. In addition to this, Qt provides much of the necessary functionality for writing
+providing a full set of traditional widgets that have been used in a number of successful
+applications. In addition to this, Qt provides many essential functionalities for writing
 cross-platform applications in general, such as I/O, SQL & XML programming, threading,
-internationalization and so on.
+internationalisation and so on.
 
-In addition to this, Qt has recently come out with a number of new subsystems:
+In addition to this, Qt has recently released a number of new subsystems:
 
  - <a href="http://doc.trolltech.com/4.6/graphicsview.html">The Graphics View Framework</a>
  - <a href="http://doc.trolltech.com/4.6/animation-overview.html">The Animation Framework</a>
@@ -58,21 +59,21 @@ In addition to this, Qt has recently come out with a number of new subsystems:
  - <a href="http://doc.trolltech.com/4.6/painting-3d.html">Low-level 3D enablers</a>
 
 These new technologies serve as the basic enablers for next-generation user interfaces. However,
-as of Qt 4.6 these elements by themselves are still fairly low level and lacking the ties to any
-ready made UI components, including the existing Qt ones. MeeGo Touch takes these cutting edge
-components and implements a particular UI style optimized for touch devices and then, combined with
+as of Qt 4.6, these elements by themselves are still fairly low-level and lack the ties to any
+ready-made UI components, including the existing Qt components. MeeGo Touch takes these cutting edge
+components and implements a particular UI style that is optimised for touch devices and then, combined with
 a number of additional enablers that makes creating scene based applications easier, packages it
 together as a coherent UI framework library.
 
 MeeGo Touch, like Qt, is also a cross-platform framework, capable of running wherever Qt does.
-From the point of view of a developer that wants to create a touch optimized application in
+From the point of view of a developer that wants to create a touch optimised application in
 the MeeGo Touch style, both Qt and MeeGo Touch are typically directly used; Qt for the application
-logic and MeeGo Touch for the scene based UI style.
+logic and MeeGo Touch for the scene-based UI style.
 
 \image html duiplatform.png Qt and MeeGo Touch, two complementary frameworks
 
-The MeeGo Touch offering includes a set of ready made widgets implementing the MeeGo Touch style that
-specifically targets the Graphics View Framework, a set of pre-defined transitions and
+The MeeGo Touch offering includes a set of ready-made widgets implementing the MeeGo Touch style that
+specifically target the Graphics View Framework, a set of pre-defined transitions and
 animations that can be themed and styled, and a set of features that makes writing scene
 based applications easier in general, such as automatic management of in-scene dialogs and
 windows, implicitly animated scene layouts and device orientation tracking. In addition to this
diff --git a/doc/src/launcher.dox b/doc/src/launcher.dox
index 06f0289a..6158d782 100644
--- a/doc/src/launcher.dox
+++ b/doc/src/launcher.dox
@@ -1,41 +1,36 @@
-/*! \page launcher How to write launchable applications
+/*! \page launcher Writing launchable applications
 
-Launcher enables starting up various types of applications very
-fast. Launcher uses different <em>booster</em> for each of the
-application types. This page concentrates on launching MeeGo Touch
+Launcher makes it possible to start up various types of applications very
+quickly. Launcher uses a different <em>booster</em> for each of the
+application types. This section concentrates on launching MeeGo Touch
 applications with the MeeGo Touch booster, but also other boosters are
-briefly introduced at the bottom of the page.
+briefly introduced at the end of the section.
 
 \section intro Introduction
 
-In order to be started up with the launcher, an application needs to
+The launcher can start an application if the following pre-requisites are met:
 
-\li take MApplication and MApplicationWindow instances into use from
+\li MApplication and MApplicationWindow instances are taken into use from
 MComponentCache
 
-\li be compiled and linked to a position independent binary
+\li application is compiled and linked to a position independent binary
 (executable or library)
 
-\li be started with the \c invoker command instead of executing the
+\li application is started with the \c invoker command instead of executing the
 executable file.
 
-In the following we will explain how the launcher works and then
-explain how to fulfill the requirements above.
-
-
 \section howitworks How the launcher works
 
-Applauncherd daemon helps launching applications faster by two
-means. First, it preloads a number of libraries, including MeeGo Touch
-and Qt libraries. This allows faster loading of application binaries
-when needed. Second, it initializes certain components before an
+Applauncherd daemon makes it possible to launch applications faster. First of all, it preloads a number of 
+libraries, including MeeGo Touch and Qt libraries. This makes it faster to load application binaries
+when needed. Secondly, it initialises certain components before an
 application is loaded and makes the results available to applications
 when they start.
 
 More technically, applauncherd forks a will-be-application process,
-a.k.a booster, before knowing which application is going to be
+also called a booster, before knowing which application is 
 launched next. Booster processes do application-type specific
-initializations. For instance, the MeeGo Touch booster instantiates
+initialisations. For instance, the MeeGo Touch booster instantiates
 MApplication and MApplicationWindow objects and stores them to
 MComponentCache. Then the booster process waits for a connection from
 the \c invoker.
@@ -43,7 +38,7 @@ the \c invoker.
 An application is invoked with the \c invoker. The invoker sends the
 booster process the name and location of the application binary and
 data on its running environment. This triggers the booster process to
-load the binary, to initialize its environment, and finally to call
+load the binary, to initialise its environment, and finally to call
 the \c main() function in the binary.
 
 Boosted MeeGo Touch applications pick up and use the already
@@ -51,28 +46,27 @@ instantiated MApplication and MApplicationWindow objects from
 MComponentCache instead of creating new ones.
 
 
-\section source Source code modifications
+\section source Modifying source code
 
 MApplication instance must be taken from the MComponentCache. It is
-recommended to take MApplicationWindow from the cache as well. That
-is, the main program should have:
+recommended to take MApplicationWindow from the cache as well. Thus, the main program should have:
 
 \code
 MApplication* application = MComponentCache::mApplication(argc, argv);
 MApplicationWindow* window = MComponentCache::mApplicationWindow();
 \endcode
 
-Note that applications that use MComponentCache can be run without the
-launcher/invoker as well. In that case MComponentCache will
-instantiate new MApplication and MApplicationWindow objects on the
+Note: Applications that use MComponentCache can be run without the
+launcher/invoker as well. In that case, MComponentCache 
+instantiates new MApplication and MApplicationWindow objects on the
 fly.
 
 The launcher needs to find the symbol \c main in an application binary
 in order to start executing the application. However, unnecessary
 symbols in the application binary cause unnecessary overhead, so the
-recommended flags for compiling for the launcher make symbols hidden
+recommended flags for compiling for the launcher hide symbols 
 by default. When the flags are used, the main function must be
-explicitly exported. It can be done as follows:
+explicitly exported as follows:
 
 \code
 #include <MExport>
@@ -84,13 +78,13 @@ M_EXPORT int main(int argc, char **argv)
 \endcode
 
 
-\section compilation Compilation and Linking
+\section compilation Compiling and linking
 
-Binaries intended to be run with applauncherd should be compiled with
-\c -fPIC option to produce position independent code. In order to
-produce a position independent executable, \c -pie option and \c
--rdynamic options can be used in linking. This allows the result to be
-executed both traditionally and with the invoker.
+To compile binaries that can be run with applauncherd, use
+\c -fPIC option to produce position-independent code. To
+produce a position-independent executable, \c -pie option and \c
+-rdynamic options can be used in linking. This makes it possible to execute the result both 
+traditionally and with the invoker.
 
 To improve linking and load times of shared object libraries the size
 of dynamic export table it is encouraged to hide the unnecessary
@@ -99,10 +93,10 @@ symbols from the resulting binary by using \c -fvisibility=hidden and
 
 \subsection qmaketips Building with QMake
 
-\subsubsection qmakepreferred The preferred way
+\subsubsection qmakepreferred Building in the preferred way
 
-Once you have installed the \c libmeegotouch-dev package,
-you can simply use QMake configuration option \c meegotouch-boostable:
+Once you have installed the \c libmeegotouch-dev package, simply use QMake configuration option 
+\c meegotouch-boostable:
 
 \code
 CONFIG += meegotouch-boostable
@@ -112,24 +106,23 @@ This tells qmake to use the \c meegotouch-boostable feature, which
 includes the \c meegotouch feature and ultimately uses \c pkg-config for the
 flags. Unfortunately qmake does not complain if you add the line but
 have not installed \c libmeegotouch-dev, so if the QMake magic does
-not seem to work, double check that the package is indeed installed.
+not seem to work, double-check that the package is indeed installed.
 
-\subsubsection qmakeother The pkg-config way
+\subsubsection qmakeother Building with pkg-config
 
-You can also use \c pkg-config to get the correct flags:
+Use the \c pkg-config to get the correct flags:
 
 \code
 QMAKE_CXXFLAGS += `pkg-config --cflags meegotouch-boostable`
 QMAKE_LFLAGS += `pkg-config --libs meegotouch-boostable`
 \endcode
 
-If \c libmeegotouch-dev is not installed, \c pkg-config will
-complain when you run \c make.
+If \c libmeegotouch-dev is not installed, \c pkg-config 
+complains when you run \c make.
 
 \subsubsection qmakelastresort The last resort
 
-It's also possible to manually define the following variables
-in the .pro file:
+Manually define the following variables in the .pro file:
 
 \code
 QMAKE_CXXFLAGS += -fPIC -fvisibility=hidden -fvisibility-inlines-hidden
@@ -141,13 +134,13 @@ required compiler and linker flags.
 
 \subsection cmaketips Building with CMake
 
-You can utilize \c pkg-config in CMake by including \c FindPkgConfig in \c CMakeLists.txt:
+1. Use \c pkg-config in CMake by including \c FindPkgConfig in \c CMakeLists.txt:
 
 \code
 include(FindPkgConfig) 
 \endcode
 
-To obtain the compiler and linker flags, add the following lines:
+2. To obtain the compiler and linker flags, add the following lines:
 
 \code
 pkg_check_modules(MEEGOTOUCH_BOOSTABLE REQUIRED meegotouch-boostable)
@@ -155,7 +148,7 @@ add_definitions(${MEEGOTOUCH_BOOSTABLE_CFLAGS})
 link_libraries(${MEEGOTOUCH_BOOSTABLE_LDFLAGS})
 \endcode  
 
-In order to install the application binary with a \c .launch filename extension, use the following
+3. To install the application binary with a \c .launch filename extension, use the following
 line:
 
 \code
@@ -163,26 +156,27 @@ install(PROGRAMS myapplication DESTINATION /usr/bin RENAME myapplication.launch)
 \endcode
 
 If you do not want to use \c pkg-config for some reason, you can manually add the
-compiler and linker flags like this:
+compiler and linker flags as follows:
 
 \code
 set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fPIC -fvisibility=hidden -fvisibility-inlines-hidden")
 set(CMAKE_EXE_LINKER_FLAGS "-pie -rdynamic")
 \endcode  
 
-Again, this requires you to update the flags if something changes.
+Again, you need to update the flags if something changes.
 
 \subsection pkgconfig Obtaining flags with pkg-config
 
 The package \c libmeegotouch-dev provides the necessary files for
 \c pkg-config to get the appropriate compiler and linker flags.
-To get the compiler flags, use
+
+1. To get the compiler flags, use the following:
 
 \code
 pkg-config --cflags meegotouch-boostable
 \endcode
 
-and to get the linker flags use
+2. To get the linker flags, use the following:
 
 \code
 pkg-config --libs meegotouch-boostable
@@ -191,7 +185,7 @@ pkg-config --libs meegotouch-boostable
 \section running Running boosted application
 
 Check that applauncherd package is installed and applancherd daemon is
-running. You can now run your application as usual like
+running. You can now run your application as usual as
 /usr/bin/application_binary, or use the mboosted launching by running:
 
 \code
@@ -201,15 +195,17 @@ invoker --type=m /usr/bin/application_binary
 
 \section debugging Debugging
 
-In order to debug launched application, the debugger must be attached
-to already running booster process. For instance, first run
+To debug a launched application, the debugger must be attached
+to an already running booster process. For instance: 
+
+1. Run the following command:
 
 \code
 gdb /usr/bin/applauncherd.bin $(pgrep booster-m)
 \endcode
 
-then set a breakpoint to the application code and let the process
-continue to that point
+2. Set a breakpoint to the application code and let the process
+continue to that point:
 
 \code
 (gdb) break main.cpp:42
@@ -221,8 +217,8 @@ Breakpoint 1 (main.cpp:42) pending.
 Continuing.
 \endcode
 
-Finally invoke the application with the booster to which the debugger
-is attached to
+3. Invoke the application with the booster to which the debugger
+is attached:
 
 \code
 invoker --type=m /usr/bin/application_binary
@@ -230,17 +226,17 @@ invoker --type=m /usr/bin/application_binary
 
 \subsection pie-binaries PIE binaries and debugging
 
-Using \c pkg-config when building your binaries makes them
+If you use the \c pkg-config when building your binaries, they are
 linked with the \c -pie flag. The \c -pie flag  makes your binaries
 \e position \e independent \e executables. This means that the executables
-can be either used as a normal shared library or run from e.g.
+can be either used as a normal shared library or run, for example, from
 the command line.
 
 This creates problems when debugging your application with gdb older than
 version 7.1 which introduced the support for PIE binaries.
 
-The solution when using gdb 7.0 or earlier is to link your binaries as
-libraries i.e. using \c -shared instead of \c -pie. After this, you can't
+To use gdb 7.0 or earlier, link your binaries as
+libraries by using \c -shared instead of \c -pie. After this, you cannot
 execute your binaries directly, you have to use \c invoker.
 
 Setting correct linker flags with QMake:
@@ -265,31 +261,31 @@ application is:
 exec /usr/bin/invoker --type=m $0.launch "$@"
 \endcode
 
-Note that even if the binary is renamed to <application_name>.launch,
+Note: Even if the binary is renamed to <application_name>.launch,
 application identifier does not change (optional parameter of
 MComponentCache::mApplication).
 
-\c .desktop and D-Bus \c .service files can be modified so that instead of
-normal execution there is
+\c .desktop and D-Bus \c .service files can be modified so that 
+normal execution is replaced with the following:
 
 \code
 Exec=/usr/bin/invoker --delay <seconds> --type=m /usr/bin/<application_name>.launch
 \endcode
 
-Note 1: when launching through D-Bus, it is important to add enough delay to invoker so that it won't exit
-before the launched application gets its D-Bus service registered. Otherwise D-Bus daemon may think that
+Note 1: When launching through D-Bus, it is important to add enough delay to invoker so that it does not exit
+before the launched application gets its D-Bus service registered. Otherwise, D-Bus daemon may think that
 the application just died. Another option is to use --wait-term which forces invoker to wait until
 the launched application exits.
 
-Note 2: There is a slight difference in application startup time if using
+Note 2: There is a slight difference in the application start-up time if you use a
 script instead of the actual binary in Exec-field of .desktop and .service files. 
-Therefore it is recommended always use the actual invoker call with the binary name
+Therefore, it is recommended that you always use the actual invoker call with the binary name
 as presented above. 
 
-Note 3: When .desktop file contains X-Maemo-Service -field application will
-be started by default through D-Bus. This might cause some delay for
-application startup time. Therefore it is recommended not to have
-X-Maemo-Service -field inside .desktop files with launched applications,
+Note 3: When .desktop file contains the X-Maemo-Service field, the application 
+is started by default through D-Bus. This might cause some delay for
+application start-up time. Therefore it is recommended not to have the 
+X-Maemo-Service field inside .desktop files with launched applications,
 unless it is really needed for some other reason.
 
 Application packages that use the launcher depend on the applauncherd
@@ -341,14 +337,13 @@ Finally, if an application has some security tokens:
 </aegis>
 \endcode
 
-
 \section limitations Limitations and known issues
 
 \subsection issue-cmdline Issues with command line arguments
 
-Current launcher implementation does not support following Qt and
-MeeGo Touch command line options (see QApplication and MApplication
-docs for more information about command options usage):
+Current launcher implementation does not support the following Qt and
+MeeGo Touch command line options. For more information about using command options, see 
+QApplication and MApplication documentation. 
 
 \li  \c -style
 \li  \c -stylesheet
@@ -378,10 +373,9 @@ docs for more information about command options usage):
 \li  \c -fullscreen
 \li  \c -disable-m-input-context
 
-QCoreApplication::arguments() returns a QStringList that containing at
-most 32 arguments and drops the rest. The full list of arguments is
-accessible through \c argc and \c argv. They can be converted into
-QStringList similar to returned by QCoreApplication::arguments() as
+QCoreApplication::arguments() returns a QStringList which contains 32 arguments at the most and 
+drops the rest. The full list of arguments is accessible through \c argc and \c argv. They can be 
+converted into QStringList similar to returned by QCoreApplication::arguments() as
 follows:
 
 \code
@@ -397,15 +391,15 @@ M_EXPORT int main(int argc, char **argv) {
 
 By default, invoker processes terminate before or right after booster
 processes have called main(). This may confuse shell scripts and
-process monitoring in D-Bus daemon and Upstart, for instance. To help
-solving these issues invoker accepts parameters
+process monitoring in D-Bus daemon and Upstart, for instance. To solve these issues, the invoker 
+accepts the following parameters:
 
 \li \c --delay \c 10 invoker waits for 10 seconds before terminating
-\li \c --wait-term invoker will not terminate until the launched
-application terminates. Invoker will return the same return value as
-the application did, or it will be terminated by the same signal as
-the launched application. Signals received by the invoker process will
-be forwarded to the launched application.
+\li \c --wait-term invoker does not terminate until the launched
+application terminates. Invoker returns the same return value as
+the application did, or it is terminated by the same signal as
+the launched application. Signals received by the invoker process are forwarded to the launched 
+application.
 
 
 \section sample Sample MeeGo Touch launchable application
@@ -434,17 +428,16 @@ M_EXPORT int main(int argc, char ** argv)
 
 \section otherboosters Other boosters
 
-Warning: behavior of these boosters is subject to change.
+Warning: Behaviour of these boosters is subject to change.
 
 Qt booster is a no-operation booster. It can be used by calling \c
 invoker \c --type=qt. Qt booster requires only the M_EXPORT source
 modification. Any MeeGo Touch boostable application can be launched
-with this booster type as well, but it will result in a slower start
-up because of empty cache.
+with this booster type as well, but it results in a slower start-up because of empty cache.
 
 Wrt booster, used with \c invoker \c --type=wrt, populates
 MComponentCache with MApplication and MApplicationWindow, just like
 the MeeGo Touch booster. However, in this case MApplication uses a
-graphics system which suits better for rendering web content.
+graphics system which is more suitable for rendering web content.
 
 */
diff --git a/doc/src/layouts.dox b/doc/src/layouts.dox
index 9cf591ea..db63b167 100644
--- a/doc/src/layouts.dox
+++ b/doc/src/layouts.dox
@@ -1,63 +1,63 @@
-/*! \page layouts Layout and Policies
+/*! \page layouts Layout and policies
 
-\section basics Basics
+\section basics Introduction
 
-MeeGo Touch includes a set of layout management classes that are used to describe how widgets are laid out in an application's user interface. These layouts automatically position and resize widgets when the amount of space available for them changes, ensuring that they are consistently arranged and that the user interface as a whole remains usable.
+MeeGo Touch includes a set of layout management classes that are used to describe how widgets are laid out in an application's user interface. These layouts automatically position and resize widgets when the amount of available space changes, which ensures that they are consistently arranged and that the user interface as a whole remains usable.
 
 There are two different sets of layout classes.
 
-The first is provided by Qt, and inherit from QGraphicsLayout, including QGraphicsLinearLayout, QGraphicsGridLayout, etc.  These Qt classes provide an easy way to layout items as you want.
+The first is provided by Qt, and inherited from QGraphicsLayout, including QGraphicsLinearLayout, QGraphicsGridLayout, and so on.  These Qt classes provide an easy way to place items as you want.
 
-The second set of layout classes is provided by MeeGo Touch, and offer additional feature, at the cost of slightly more overhead.  The MeeGo Touch classes work in a slightly different way - there is a single MLayout to which you can add one or more policies that inherit MAbstractLayoutPolicy.  This allows a single layout to have multiple policies, with one active at a given time.  A different policy can be made active at any time, causing the items within the layout to move into their new position.
+The second set of layout classes is provided by MeeGo Touch, and they offer additional features, at the cost of slightly more overhead.  The MeeGo Touch classes work in a slightly different way - there is a single MLayout to which you can add one or more policies that inherit MAbstractLayoutPolicy.  This allows a single layout to have multiple policies, with one active at a given time.  A different policy can be made active at any time, causing the items within the layout to move into their new position.
 
-The multiple policies in a single MLayout do not even need to contain the same items.  New items will be shown and hidden as necessary (Unless the item is itself a layout, since a layout cannot be directly hidden itself, but a layout inside of a widget inside of a layout will be hidden.  See \ref layout-inside-layout).
+The multiple policies in a single MLayout do not even need to contain the same items.  New items are shown and hidden as necessary (Unless the item is itself a layout, since a layout cannot be directly hidden itself. However, if a layout is inside a widget which is inside a layout, it is hidden.  See \ref layout-inside-layout).
 
-\section tips Tips for Using Layouts
-\li When you use a layout or layout policy, you do not need to pass a parent when constructing the child widgets. The layout will automatically reparent the widgets so that they are children of the widget on which the layout is installed.  When the parent widget is deleted, its layout and all of its children are also deleted.
+\section tips Tips for using layouts
+\li When you use a layout or layout policy, you do not need to pass a parent when constructing the child widgets. The layout automatically reparents the widgets so that they are children of the widget on which the layout is installed.  When the parent widget is deleted, its layout and all of its children are also deleted.
 
 \li Widgets in a layout are children of the widget on which the layout is installed, not of the layout itself. Widgets can only have other widgets as parent, not layouts.  You can nest layouts using addLayout() on a layout; the inner layout then becomes a child of the layout it is inserted into.
 
-\li You can have one policy when in landscape mode and another policy when portrait mode.  You do not even need to have the same items in each case.
+\li You can have one policy in landscape mode and another policy in portrait mode.  You do not even need to have the same items in both modes.
 
 \li If you only want to switch between a horizontal and vertical linear layout policy, you can use MLinearLayoutPolicy::setOrientation() instead of multiple policies.
 
-\li For a complex set of nested layouts it is easier and more lightweight to use nested \link QGraphicsLayout QGraphicsLayouts\endlink than to try to nest \link MLayout MLayouts \endlink.
+\li For a complex set of nested layouts, it is easier and more lightweight to use nested \link QGraphicsLayout QGraphicsLayouts\endlink than to try to nest \link MLayout MLayouts \endlink.
 
-\li See the QLayout and QGraphicsLayout documentation for more information and tips, and see the examples.
+\li For more information, tips, and examples, see the QLayout and QGraphicsLayout documentation.
 
-\section rtl Right-to-left
+\section rtl Right-to-left layouts
 
-In right-to-left languages, such as arabic, the layouts are automatically reversed.  This is usually the correct behavior, however you can override this by directly calling
+In right-to-left languages, such as Arabic, the layouts are automatically reversed.  This is usually the correct behaviour. However, you can override this by directly calling
 QGraphicsWidget::setLayoutDirection().
-For example the calculator example has the following code snippet:
+For example, the calculator example has the following code snippet:
 
 \dontinclude calculator/calculatorwidget.cpp
 \skip CalculatorWidget::CalculatorWidget
 \until MLayout *layout
 
-\section pagelayout-widgetSize Widget Sizes
+\section pagelayout-widgetSize Widget sizes
 
-To determine the size of a widget in a layout, the layout uses the widget's QGraphicsLayoutItem::preferredSize() and its QGraphicsLayoutItem::sizePolicy() functions.  The preferred size of a MWidgetController is determined from:
+To determine the size of a widget in a layout, the layout uses the widget's QGraphicsLayoutItem::preferredSize() and its QGraphicsLayoutItem::sizePolicy() functions.  The preferred size of a MWidgetController is determined as follows:
 
 -# The constraint passed to the MWidgetController::sizeHint() function - usually due to the layout.
--# Developer set hints (using QGraphicsLayoutItem::setPreferredSize(), etc).
--# Style set size (e.g. from the CSS files).
+-# Developer set hints (using QGraphicsLayoutItem::setPreferredSize(), and so on).
+-# Style set size (for example, from the CSS files).
 -# View's MWidgetView::sizeHint() function.
 -# MWidgetController::layout()->QGraphicsLayoutItem::sizeHint() function.
 
-The sizes given from the first 3 steps are combined, in the order of preference as shown.
-If the height and/or width is not specified, then the MWidgetView::sizeHint() function is called, with
+The sizes given from the first 3 steps are combined, in the above order of preference.
+If the height and/or width are not specified, the MWidgetView::sizeHint() function is called, with
 \a constraint parameter set to the size determined so far.  The result from the view is then combined with
 the constraint.
 
 Finally, if this size is still not valid, the size is combined with QGraphicsWidget::sizeHint() which
 in turn uses the layout's QGraphicsLayoutItem::sizeHint() function.
 
-If you create your widget and its width depends on its height, then its size policy must have set QSizePolicy::hasHeightForWidth().
+If you create your widget and its width depends on its height, its size policy must have set QSizePolicy::hasHeightForWidth().
 
 \see MWidgetView::sizeHint()
 
-\section main Main Policies
+\section main Main policies
 \li MLinearLayoutPolicy - For placing items horizontally or vertically:
 
 \image html mlinearlayoutpolicy.jpg
@@ -66,33 +66,37 @@ If you create your widget and its width depends on its height, then its size pol
 
 \image html mgridlayoutpolicy.jpg
 
-\li MFlowLayoutPolicy - For placing items in a horizontal line, overflowing onto the next line:
+\li MFlowLayoutPolicy - For placing items on a horizontal line, overflowing onto the next line:
 
 \image html mflowlayoutpolicy.jpg
 
-\li MFreestyleLayoutPolicy - For placing items freely, but still preventing items from overlapping:
+\li MFreestyleLayoutPolicy - For placing items freely, but preventing items from overlapping:
 
 \image html mfreestylelayoutpolicy.jpg
 
-\section multiple Multiple Policies
+\section multiple Multiple policies
 
-Multiple policies can be assigned to a layout.  This is particularly useful to have one policy when in portrait mode and another when in landscape mode. For \ref layout-multiplepolicies "example":
+Multiple policies can be assigned to a layout.  It is particularly useful to have one policy in 
+portrait mode and another policy in landscape mode. For \ref layout-multiplepolicies "example":
 
 \image html mlayout_multiplepolicies.jpg
 
-A more concrete example is given with the \ref example-calculator "example calculator" program.
+A more concrete example is given with the \ref example-calculator "example calculator" application.
 
 \htmlonly <center><a href="example-calculator.html"><img src="calculator_landscape_small.png"></a>
 <a href="example-calculator.html"><img src="calculator_portrait_small.png"></a></center> \endhtmlonly
 
 \sa \ref layout-multiplepolicies, \ref example-calculator, \ref layout-inside-layout, MLayout
 
-\section usingqgraphicslayout More complex layouting using QGraphicsLayout
+\section usingqgraphicslayout Advanced layout with QGraphicsLayout
 
-For a more complex layout of items, you can place multiple layouts together.  This is easiest using a mix of
-MLayouts and QGraphicsLayout, using a MLayout only when animations and multiple policies are required.
+For advanced item layout, you can place multiple layouts together.  The easiest way to do this is 
+to use a mix of MLayouts and QGraphicsLayout, and use a MLayout only when animations and multiple 
+policies are required.
 
-For example using multiple \link QGraphicsLinearLayout QGraphicsLinearLayouts \endlink we can obtain a layout where items are laid in rows, but the items do not line up vertically. For \ref layout-qgraphicslayout "example":
+For example, if you use multiple \link QGraphicsLinearLayout QGraphicsLinearLayouts \endlink, you 
+create a layout where items are placed in rows, but they do not line up vertically. 
+For \ref layout-qgraphicslayout "example":
 
 \image html qgraphicslayout_small.png
 
diff --git a/doc/src/license.dox b/doc/src/license.dox
index cbe65cc4..7a82d412 100644
--- a/doc/src/license.dox
+++ b/doc/src/license.dox
@@ -1,13 +1,13 @@
-/*! \page license License
+/*! \page license Licence
 
 \verbatim
 
                   GNU LESSER GENERAL PUBLIC LICENSE
 
- The DirectUI Framework is Copyright (C) 2010 Nokia Corporation and/or its subsidiary(-ies).
- Contact: Nokia Corporation (directui@nokia.com)
+ The MeeGo Touch Framework is Copyright (C) 2010 Nokia Corporation and/or its subsidiary(-ies).
+ Contact: Nokia Corporation (meego-touch@meego.com)
 
- You may use, distribute and copy the DirectUI Framework under the terms of
+ You may use, distribute and copy the MeeGo Touch Framework under the terms of
  GNU Lesser General Public License version 2.1, which is displayed below.
 
 -------------------------------------------------------------------------
diff --git a/doc/src/logicalid.dox b/doc/src/logicalid.dox
index 2ca939b7..468500c8 100644
--- a/doc/src/logicalid.dox
+++ b/doc/src/logicalid.dox
@@ -2,38 +2,37 @@
 
 \section graphics Graphics
 
-A <em>logical ID</em> is a way to unambiguously refer to a particular piece of graphics from
-the <em>theme</em>. Each and every asset from the theme, be it an icon, a background image, or a piece
-of a widget graphics, has such an ID.
+A <em>logical ID</em> is a way to unambiguously refer to graphics from the <em>theme</em>. Each and 
+every asset from the theme, be it an icon, a background image, or a widget graphics object, has such an ID.
 
-The ID abstracts the actual format of the graphic from the application developer, and allows
+The ID abstracts the actual graphics format from the application developer, and allows
 MeeGo Touch to automatically switch the graphics when the theme changes to match the new look.
 
 \section logicalid_usage Using logical IDs
 
-Logical IDs are typically used in the following ways:
+Logical IDs are typically used:
 
-- In MeeGo Touch widget methods that take an ID
-- Requesting a piece of graphic directly from the theme system
+- In MeeGo Touch widget methods that require an ID
+- To request graphics directly from the theme system
 - In the CSS files of applications and libraries
 
-Examples of methods that accept an logical ID include:
+Examples of methods that accept a logical ID:
 
  - MImageWidget::setImage(const QString &id, const QSize &size)
  - MAction::setIconID(const QString &id)
  - MComboBox::setIconID(const QString &id)
  - MContentItem::setImageID(const QString &id, const QSize &size)
 
-\note If a size is not provided when requesting a graphic by logical ID, whatever size the graphics
-was created with in the theme itself is used which can produce unexpected results. You should
+\note If a size is not provided when requesting graphics by logical ID, the size in which the 
+graphics were created in the theme itself is used, which can produce unexpected results. You should
 therefore always provide a size, the only exception being MAction and MComboBox type of APIs where
 the component itself already knows the exact size of the graphics.
 
-By providing a logical ID instead of a QPixmap or QImage to a widget, you can be sure that the widget
-will be updated when the theme changes.
+To ensure that a widget is updated when the theme changes, provide a logical ID to the widget instead of a 
+QPixmap or QImage.
 
-In case you are implementing a widget yourself, or you require a direct handle to the graphics for
-some other reason, it is possible to request a QPixmap containing a particular themed graphics
+In case you are implementing a widget yourself or you require a direct handle to the graphics for
+some other reason, you can request a QPixmap containing particular themed graphics
 using MTheme::pixmap(const QString &id, const QSize &size).
 
 In MeeGo Touch CSS files, a logical ID can be provided for style attributes that are of MScalaleImage or QPixmap types:
@@ -46,13 +45,13 @@ MButtonSwitchStyle {
 }
 \endcode
 
-\section logicalid_mapping Mapping graphics to Logical IDs
+\section logicalid_mapping Mapping graphics to logical IDs
 
-A themed graphical asset may be either a static image on the filesystem, or a single element
-or group inside a SVG document. The rules for mapping a logical ID to a piece of graphics is as follows:
+A themed graphical asset may be either a static image on the file system, or a single element
+or group inside an SVG document. The rules for mapping a logical ID to graphics are:
 
-- The \ref theme_structure "Theme Structure" is searched for graphical assets (SVG's, PNG, JPEGs, etc.)
-- If a static image's <em>filename</em> without the suffix (PNG, JPEG, etc.) matches the logical ID, it is selected.
+- The \ref theme_structure "Theme Structure" is searched for graphical assets (SVGs, PNG, JPEGs, and so on).
+- If a static image's <em>filename</em> without the suffix (PNG, JPEG, and so one) matches the logical ID, it is selected.
 - If a single element's or a group's <em>Object ID</em> in an SVG document matches the logical ID, it is selected.
   - The filename of the actual SVG is not relevant to the selection
   - A single SVG file can contain any number of themed graphical elements
diff --git a/doc/src/mainclasses.dox b/doc/src/mainclasses.dox
index 9e11dd0f..ab6689bd 100644
--- a/doc/src/mainclasses.dox
+++ b/doc/src/mainclasses.dox
@@ -1,4 +1,4 @@
-/*! \page mainclasses Main Classes
+/*! \page mainclasses Main classes
 
 Core application classes
 <ul>
@@ -7,19 +7,19 @@ Core application classes
 <li>MApplicationWindow
 </ul>
 
-Action extensions
+Action extension classes
 <ul>
 <li>MAction
 <li>MWidgetAction
 </ul>
 
-Notifications
+Notification classes
 <ul>
 <li>MNotification
 <li>MNotificationGroup
 </ul>
 
-Widgets
+Widget classes
 <ul>
 <li>MButton
 <li>MComboBox
@@ -47,7 +47,7 @@ Widgets
 <li>MTextEdit
 </ul>
 
-Layouting and grouping
+Layouting and grouping classes
 <ul>
 <li>MButtonGroup
 <li>MLayout
diff --git a/doc/src/mainpage.dox b/doc/src/mainpage.dox
index b25eb80e..a2073f48 100644
--- a/doc/src/mainpage.dox
+++ b/doc/src/mainpage.dox
@@ -2,49 +2,49 @@
 
 <table class="mainIndex" class="indextable" cellspacing="1" cellpadding="2" border="0" align="center" width="95%">
   <tr>
-    <th>Getting Started</th>
-    <th>API Reference</th>
-    <th>Developer References</th>
+    <th>Getting started</th>
+    <th>API reference</th>
+    <th>Developer references</th>
   </tr>
   <tr>
     <td>
       <ul>
        <li><strong><a href="introduction.html">Introduction to MeeGo Touch</a></strong></li>
        <li><a href="installation.html">Installing MeeGo Touch</a></li>
-       <li><strong><a href="tutorial.html">Your first MeeGo Touch application</a></strong></li>
-       <li><strong><a href="news.html">What's New in MeeGo Touch</a></strong></li>
+       <li><strong><a href="tutorial.html">Creating your first MeeGo Touch application</a></strong></li>
+       <li><strong><a href="news.html">What's new in MeeGo Touch</a></strong></li>
       </ul>
     </td>
     <td>
       <ul>
-       <li><strong><a href="mainclasses.html">Main Classes</a></strong></li>
-       <li><a href="classes.html">All Classes</a></li>
-       <li><a href="annotated.html">Annotated Classes</a></li>
-       <li><a href="namespaces.html">All Namespaces</a></li>
-       <li><a href="hierarchy.html">Inheritance Hierarchy</a></li>
-       <li><a href="deprecated.html">Deprecated List</a></li>
+       <li><strong><a href="mainclasses.html">Main classes</a></strong></li>
+       <li><a href="classes.html">All classes</a></li>
+       <li><a href="annotated.html">Annotated classes</a></li>
+       <li><a href="namespaces.html">All namespaces</a></li>
+       <li><a href="hierarchy.html">Inheritance hierarchy</a></li>
+       <li><a href="deprecated.html">Deprecated list</a></li>
       </ul>
     </td>
     <td>
       <ul>
        <li><strong><a href="http://meego.gitorious.org/meegotouch/libmeegotouch">Code repository</a></strong></li>
        <li><a href="http://meego.gitorious.org/meegotouch/pages/Home">MeeGo Touch Wiki</a></li>
-       <li><a href="bugreporting.html">How to Report a Bug</a></li>
+       <li><a href="bugreporting.html">Reporting a bug</a></li>
        <li><a href="credits.html">Credits</a></li>
-       <li><a href="license.html">License</a></li>
+       <li><a href="license.html">Licence</a></li>
       </ul>
     </td>
   </tr>
 
   <tr>
-    <th colspan=3>MeeGo Touch Overviews</th>
+    <th colspan=3>MeeGo Touch overviews</th>
   </tr>
   <tr>
     <td>
       <ul>
        <li><a href="commoncomponents.html">Common components</a>
-       <li><a href="layouts.html">Layouts</a></li>
-       <li><a href="i18n.html">Internationalization</a></li>
+       <li><a href="layouts.html">Layout and policies</a></li>
+       <li><a href="i18n.html">Internationalisation</a></li>
        <li><a href="styling.html">Styling</a></li>
        <li><a href="gestures.html">Gestures</a></li>
       </ul>
@@ -52,19 +52,19 @@
     <td>
       <ul>
        <li>\subpage rotation</li>
-       <li><a href="faststart.html">Fast application startup</a></li>
-       <li><a href="notifications.html">Notifications</a></li>
-       <li>\subpage sceneandscenewindows "The scene and its scene windows"</li>
+       <li><a href="faststart.html">Reducing application start-up time</a></li>
+       <li><a href="notifications.html">Notification system</a></li>
+       <li>\subpage sceneandscenewindows "Scene and scene windows"</li>
        <li>\subpage input_feedback "Input feedback"</li>
       </ul>
     </td>
     <td>
       <ul>
-       <li><a href="applicationextensions.html">Application extensions</a></li>
+       <li><a href="applicationextensions.html">Developing application extensions</a></li>
        <li><a href="settingslanguageschema.html">Settings language reference</a></li>
        <li><a href="plainqt.html">Developing Qt applications for Maemo 5 and MeeGo</a></li>
-       <li><a href="servicefw.html">MeeGo Touch Service Framework</a></li>
-       <li><a href="debugginginfo.html">MeeGo Touch Debugging Information</a></li>
+       <li><a href="servicefw.html">Service framework</a></li>
+       <li><a href="debugginginfo.html">MeeGo Touch debugging functions</a></li>
       </ul>
     </td>
   </tr>
diff --git a/doc/src/news.dox b/doc/src/news.dox
index 64ed8357..af04ed02 100644
--- a/doc/src/news.dox
+++ b/doc/src/news.dox
@@ -1,4 +1,4 @@
-/*! \page news What's New in MeeGo Touch
+/*! \page news What's new in MeeGo Touch
 
 \section v02054 0.20.54
 
diff --git a/doc/src/notifications.dox b/doc/src/notifications.dox
index 716bb464..d8dfeca4 100644
--- a/doc/src/notifications.dox
+++ b/doc/src/notifications.dox
@@ -1,45 +1,45 @@
-/*! \page notifications Notifications System
+/*! \page notifications Notification system
 
-The MeeGo Touch environment offers a notification system framework. Applications and other processes can use the notification system to inform the user about specific events. For example, the notification system can be used to inform the user about
+The MeeGo Touch environment offers a notification system framework. Applications and other processes can use the notification system to inform the user about specific events such as:
 
 - incoming emails
 - new instant messages
 - missed calls
 
-The notification system should not be used for temporary situations like various error cases. A simple \c MInfoBanner is more suitable for the following situations (for example):
+The notification system should not be used for temporary situations like various error cases. A simple \c MInfoBanner is more suitable for situations, such as:
 
 - the user interacts with an application in a way that leads to an error case
-- message to the user after the user has done something (e.g. "file deleted successfully")
+- message to the user after the user has done something (for example, "file deleted successfully")
 
-A notification is usually represented to the user with for example graphical, aural or tactile feedback - or a combination of these. The MeeGo Touch notification API hides these details under the unified API. The system determines what kind of feedback should be used to present the notifications to the user. This means that the user of the notification system doesn't have exact control over how the notification is actually presented to the user.
+A notification is usually represented to the user, for example, with graphical, aural or tactile feedback - or a combination of these. The MeeGo Touch notification API hides these details under the unified API. The system determines what kind of feedback is used to present the notifications to the user. This means that the user of the notification system cannot directly control how the notification is actually presented to the user.
 
-The notifications can be grouped. It is up to the underlying system how grouped notifications will be shown. A usual way is to for example show one visual banner to the user representing a group of notifications. A notification group can have almost the same parameters - and hence e.g. visualisation - that single notifications have.
+The notifications can be grouped. It is up to the underlying system how grouped notifications are shown. It is common that, for example, a group of notifications is displayed with one visual banner. A notification group can have almost the same parameters - including, for instance, visualisation - as single notifications.
 
 The relevant classes to developers are \c MNotification and \c MNotificationGroup. A notification can be created by constructing an object of type \c MNotification and a notification group can be created by constructing an object of type \c MNotificationGroup. After the relevant parameters have been set the notifications and the notification groups must be published before they appear by calling the publish() function. The notification group must be published before a notification can be placed into it.
 
 \section parameters Notification parameters
 
-There are similar parameters associated with both of these classes. Some of them are explained here.
+This section describes some of the parameters associated with the \c MNotification and \c MNotificationGroup classes. There are similar parameters related to both classes.
 
 \subsection eventType Event type
 
-Notifications' presentation to the user is affected by the notification's event type. For example some specific sound could be played when a new e-mail arrives. The e-mail application would only set the correct event type for the notification and the notification system would take care of the rest. Similarly other parameters such as icons and images can be selected according to the event type.
+This parameter determines how the notification is presented to the user. For example, a specific sound can be played when a new e-mail arrives. The e-mail application only sets the correct event type for the notification and the notification system takes care of the rest. Similarly, other parameters, such as icons and images, can be selected according to the event type.
 
-Users of the notification system should always set the event type correctly. Users must not set the event type wrongly just to try to get some specific feedback (e.g. sound). For this the user can provide its own event type configuration as the event type system supports 3rd party event types. The event type naming follows the <a href="http://www.galago-project.org/specs/notification/0.9/x211.html">Category</a> naming in the <a href="http://www.galago-project.org/specs/notification/0.9/index.html">Desktop Notifications Specification</a>.
+Users of the notification system must always set the event type correctly. They should not set an incorrect event type to get a specific feedback (for example, sound). To get a specific feedback, you can provide your own event type configuration as the event type system supports 3rd party event types. The event type naming follows the <a href="http://www.galago-project.org/specs/notification/0.9/x211.html">Category</a> naming in the <a href="http://www.galago-project.org/specs/notification/0.9/index.html">Desktop Notifications Specification</a>.
 
 The predefined event types that are guaranteed to exist in the system are defined in the \c MNotification documentation under Static Public Attributes.
 
 \subsection action Action
 
-The action parameter specifies an action related to the notification. The action is usually triggered by something the user does. The action is returned to the application that sent the notification.
+This parameter specifies an action related to the notification. The action is usually triggered by something the user does. The action is returned to the application that sent the notification.
 
-A typical user scenario would be for example the following. An e-mail application receives a new e-mail and sends a notification about this. The user sees a graphical notification on the screen and clicks it. The action related to the notification is triggered which commands the e-mail application to show the recently received e-mail.
+For example, an e-mail application receives a new e-mail and sends a notification about this. The user sees a graphical notification on the screen and taps it. The notification-related action is triggered and it causes the e-mail application to show the recently received e-mail.
 
-From the above example it comes obvious that notification actions are application specific.
+As illustrated in the above example, notification actions are application-specific.
 
 \subsection image Image
 
-Specifies an image that is related to the notification. Usually this means that the image is shown in a graphical representation of the notification. The image parameter can be a logical name like 'Icon-messages' or an absolute path to an image file (e.g. <em>%/usr/share/pixmaps/foo.png</em>).
+This parameter specifies an image related to the notification. Usually this means that the image is shown in a graphical representation of the notification. The image parameter can be a logical name (such as 'Icon-messages') or an absolute path to an image file (such as <em>%/usr/share/pixmaps/foo.png</em>).
 
 \subsection identifier Identifier
 
@@ -47,7 +47,7 @@ The identifier is a string that the application can use to identify a particular
 
 \subsection persistence Persistence
 
-Notifications can be created as persistent, in which case the notification system stores the notifications and they are restored after a reboot. The user can get a list of stored notifications with a call to the static function \c MNotification::notifications() and the list of groups with \c MNotificationGroup::notificationGroups().
+This parameter specifies that the notification system stores the notifications and they are restored after a reboot. The user can get a list of stored notifications with a call to the static function \c MNotification::notifications() and the list of groups with \c MNotificationGroup::notificationGroups().
 
 \see
 
diff --git a/doc/src/pagenavigation.dox b/doc/src/pagenavigation.dox
index c813ff1e..946af400 100644
--- a/doc/src/pagenavigation.dox
+++ b/doc/src/pagenavigation.dox
@@ -1,27 +1,27 @@
-/*! \page pagenavigation Navigation within your applications
+/*! \page pagenavigation Navigation patterns for applications
 
-Applications may vary in navigational patterns. Three main templates have
-been created to help support the application's main functional goals.
+Applications can have different navigation patterns. There are three main templates available to suit the
+functional goals of your application.
 
-\section pagenavigation_drilldown Drill Down
+\section pagenavigation_drilldown Drill-down template
 
-This is the most scalable template, used when access to all application navigation structure is needed on the top level. Layouts are not restricted to lists. The Close button gets replaced by a Back button, as the user drills down the structure.
+This template is the most scalable option. Use the drill-down template when you need access to the entire application navigation structure on the top level. Layouts are not restricted to lists. The Close button is replaced with a Back button when the user drills down the structure.
 
 \image html "pagenavigation_drilldown.png"
 
 \subpage pagenavigation_drilldown_example
 
-\section pagenavigation_menu Navigation in Application Menu
+\section pagenavigation_menu Application menu template
 
-This template is for flat experiences, prioritizing content over navigation structure. Application Menu is used for hopping between navigational options. This allows for many navigational options, as opposed to the Tab Bar template (below). As all these navigation points work as the top level of the application, the close button remains even after a navigational change.
+This template is intended for flat experiences, and prioritises content over navigation structure. Application menu is used for hopping between navigation options. There are many navigation options, as opposed to the tab bar template described in the following section. As all the navigation points work as the top level of the application, the Close button remains even after a navigation change.
 
 \image html "pagenavigation_menu.png"
 
 \subpage pagenavigation_menu_example
 
-\section pagenavigation_tab Tab Bar
+\section pagenavigation_tab Tab bar template
 
-This template is for quick access between distinct areas or modes. Be careful about mixing actions (like “Create New Message”) with navigational links in the Tab Bar. Use buttons within the content area for actions, if necessary, in this layout. This model is limited to maximum 4 navigation options. Navigational options in an application should not change over time.
+This template is intended for quick access between distinct areas or modes. Be careful about mixing actions (like “Create New Message”) with navigation links in the tab bar. Use buttons within the content area for actions, if necessary, in this layout. This model is limited to a maximum of 4 navigation options. Navigation options in an application should not change over time.
 
 \image html "pagenavigation_tab.png"
 
diff --git a/doc/src/pagenavigation_drilldown_example.dox b/doc/src/pagenavigation_drilldown_example.dox
index ef1b554e..68e0a296 100644
--- a/doc/src/pagenavigation_drilldown_example.dox
+++ b/doc/src/pagenavigation_drilldown_example.dox
@@ -1,8 +1,8 @@
-/*! \page pagenavigation_drilldown_example Drill Down Navigational Pattern Code Example
+/*! \page pagenavigation_drilldown_example Example of a drill-down navigation pattern
 
-Of all navigational patterns (drill down, application menu and tab bar) this is the easiest to implement. Since a page's escapeMode() is by default set to MApplicationPageModel::EscapeAuto, MeeGo Touch will take care of showing either a back button or a close button when a new page appears according to the page navigation history (MSceneManager::pageHistory()). MeeGo Touch will also automatically dismiss the current page when the back button is clicked, which will cause the previous one (i.e., the most recent in the page navigation history) to come back.
+This is the easiest navigation pattern to implement. Since escapeMode() of a page is by default set to MApplicationPageModel::EscapeAuto, MeeGo Touch either shows  a Back button or a Close button when a new page appears, according to the page navigation history (MSceneManager::pageHistory()). When the Back button is clicked, MeeGo Touch automatically dismisses the current page and displays the previous page (in other words, the most recent page in the page navigation history).
 
-Thus all you need to do is to make your next page appear. MeeGo Touch will take care of the rest.
+To implement this navigation pattern, create the required pages, and MeeGo Touch takes care of the rest.
 
 All files can be found at:
 \verbatim
diff --git a/doc/src/pagenavigation_menu_example.dox b/doc/src/pagenavigation_menu_example.dox
index 77bd0771..4ea00bfc 100644
--- a/doc/src/pagenavigation_menu_example.dox
+++ b/doc/src/pagenavigation_menu_example.dox
@@ -1,25 +1,26 @@
-/*! \page pagenavigation_menu_example Application Menu Navigational Pattern Code Example
+/*! \page pagenavigation_menu_example Example of an application menu navigation pattern
 
-Those are the three main points for implementing this navigational pattern:
-  - Add actions to the MApplicationWindow and have their locations set to MAction::ApplicationMenuLocation so that they appear in the application menu.
+There are three steps in the implementation process of this navigation pattern:
+
+1. Add actions to the MApplicationWindow and set their locations to MAction::ApplicationMenuLocation so that they appear in the application menu.
 \code
 action->setLocation(MAction::ApplicationMenuLocation);
 applicationWindow->addAction(action);
 \endcode
 
-  - Connect the triggered() signal of those actions to slots that make the corresponding pages appear.
+2. Connect the triggered() signal of the actions to the slots that display the corresponding pages.
 \code
 window->connect(settingsAction, SIGNAL(triggered()), SLOT(showSettingsPage()));
 \endcode
 
-  - Have the MApplicationPage::escapeMode() of your pages set to MApplicationPageModel::EscapeCloseWindow, otherwise the escape button will behave like in a drill down navigational pattern.
+3. Set the MApplicationPage::escapeMode() of your pages to MApplicationPageModel::EscapeCloseWindow. Otherwise the Escape button behaves as in a drill-down navigation pattern.
 \code
 page->setEscapeMode(MApplicationPageModel::EscapeCloseWindow);
 \endcode
 
-Optionally, as was done in this example, you could hide or disable the menu option (i.e. MApplicationWindow action whose location is set to ApplicationMenu) that corresponds to the page that is currently being displayed.
+You can optionally hide or disable the menu option (in other words, MApplicationWindow action located in the application menu) that corresponds to the currently displayed page.
 
-In this example the actions were grouped in a QActionGroup only because I wanted the same method to be called whenever any of those actions are triggered.
+In this example, the actions are grouped in a QActionGroup so that the same method is called whenever any of the actions is triggered.
 
 All files can be found at:
 \verbatim
diff --git a/doc/src/pagenavigation_tab_example.dox b/doc/src/pagenavigation_tab_example.dox
index 9ecf02bb..c1a0c360 100644
--- a/doc/src/pagenavigation_tab_example.dox
+++ b/doc/src/pagenavigation_tab_example.dox
@@ -1,27 +1,29 @@
-/*! \page pagenavigation_tab_example Tab Bar Navigational Pattern Code Example
+/*! \page pagenavigation_tab_example Example of a tab bar navigation pattern
 
-Those are the four main points for implementing this navigational pattern:
-  - We want the toolbar to show actions as tabs. I.e., be a tab bar. Therefore set the view type of your application window's toolbar to tab.
+There are four steps in the implementation process of this navigation pattern:
+
+1. Set your application to display actions as tabs in the toolbar, in other words, in a tab bar: 
 \code
 setToolbarViewType(MToolBar::tabType);
 \endcode
 
-  - Add actions to the MApplicationWindow and have their locations set to MAction::ToolBarLocation so that they appear in the toolbar.
+2.  Add actions to the MApplicationWindow and set their locations to MAction::ToolBarLocation so that they appear in the toolbar.
 \code
 action->setLocation(MAction::ToolBarLocation);
 applicationWindow->addAction(action);
 \endcode
 
-  - Connect the triggered() signal of those actions to slots that make the corresponding pages appear.
+3.  Connect the triggered() signal of the actions to slots that display the corresponding pages.
 \code
 window->connect(settingsAction, SIGNAL(triggered()), SLOT(showSettingsPage()));
 \endcode
-  - Have the MApplicationPage::escapeMode() of your pages set to MApplicationPageModel::EscapeCloseWindow, otherwise the escape button will behave like in a drill down navigational pattern.
+
+4. Set the MApplicationPage::escapeMode() of your pages to MApplicationPageModel::EscapeCloseWindow, otherwise the Escape button behaves as in a drill-down navigational pattern.
 \code
 page->setEscapeMode(MApplicationPageModel::EscapeCloseWindow);
 \endcode
 
-In this example the actions were grouped in a QActionGroup only because I wanted the same method to be called whenever any of those actions are triggered.
+In this example, the actions are grouped in a QActionGroup so that the same method is called whenever any of the actions is triggered.
 
 All files can be found at:
 \verbatim
diff --git a/doc/src/plainqt.dox b/doc/src/plainqt.dox
index c127d334..ffa3f3e2 100644
--- a/doc/src/plainqt.dox
+++ b/doc/src/plainqt.dox
@@ -1,48 +1,47 @@
 %TOC%
-/*! \page plainqt How to develop Qt applications for Maemo 5 and MeeGo
+/*! \page plainqt Developing Qt applications for Maemo 5 and MeeGo
 
 
 \section  audience  Audience
 
-This document targets established Qt developers who would like to use Qt to develop an application for Maemo5 or MeeGo, without the need to use the native frameworks, Hildon and MeeGo Touch respectively. Native development is not covered in this document.
+This section targets established Qt developers who would like to use Qt to develop an application for Maemo 5 or MeeGo, without the need to use the native frameworks, Hildon and MeeGo Touch, respectively. Native development is not covered in this section.
 
 
 \section  intro  Introduction
 
-Qt is a cross platform development framework. So the same source code for a Qt application can be compiled on different operating systems without changes and without any custom code. As a result your application will visually integrate into the given environment no matter whether it's Linux, Windows or Mac OS X.
+Since Qt is a cross-platform development framework, the same source code for a Qt application can be compiled on different operating systems without changes and without any custom code. As a result, your application visually integrates into the given environment, whether it is Linux, Windows, or Mac OS X.
 
-Of course this is also true for Maemo 5 and MeeGo: So compiling your Qt desktop application on the Maemo plattform will result in an application that will come very close to the native look and feel: On Maemo 5 your application will mimic the theming and the habits of applications that are built on top of the Hildon framework. And on MeeGo it will emulate the appearance and the behavior of "native" MeeGo Touch applications.
-
-However there are several cases where the mobile form factor and the philosophy behind MeeGo Touch should be kept in mind when developing a Qt application that is supposed to be used on the MeeGo Touch platform. To address these and to guarantee a good experience for your users here are a few recommendations:
+This is, of course, also true for Maemo 5 and MeeGo. Compiling your Qt desktop application on the Maemo platform results in an application that comes very close to the native look and feel. On Maemo 5, your application mimics the theming and the habits of applications that are built on top of the Hildon framework. On MeeGo, it emulates the appearance and the behaviour of "native" MeeGo Touch applications.
 
+When developing a Qt application for the MeeGo Touch platform, keep the mobile environment and the philosophy behind MeeGo Touch in mind. The following sections give some guidelines for ensuring a good user experience.
 
 \section  style  How Maemo 5 and MeeGo affect the look and feel of your application
 
-For both Maemo 5 and MeeGo your Qt application will adjust in terms of look and feel so that it will emulate the user interface of each platform:
+Your Qt application adjusts its look and feel on both Maemo 5 and MeeGo to emulate the user interface of each platform:
 
 - The "Maemo 5" style emulates the appearance of the Gtk-based Hildon framework. The Maemo 5 style is included with the special version of Qt that is shipped together with the N900 device series.
 - The "MeeGo" style mimics the widgets and interaction that is typical for the Qt-based MeeGo Touch framework. The MeeGo Touch style is part of the libmeegotouch framework and is shipped as one of its packages.
 
-Both styles take theme changes automatically into account. But the style is only an approximation of what a truly native application would look like. So there might be slight differences in terms of look and behaviour compared to a "real" Maemo 5 or MeeGo application. These differences can be reduced by taking certain typical requirements of these platforms into account.
+Both styles take theme changes automatically into account. However, since the style is not identical to a truly native application, there can be slight differences in terms of look and behaviour compared to a "real" Maemo 5 or MeeGo application. You can reduce these differences by taking certain typical requirements of the platforms into account.
 
-While the target framework and the implementations are different both styles share several characteristics. So if your style looks fine on one of the two platforms then it's quite likely that it will have a comparable appearance on the other platform as well.
+While the target framework and the implementations are different, both styles share several characteristics. Thus, if your style looks fine on one of the two platforms, it is quite likely that it has a comparable appearance on the other platform as well.
 
-Maemo5 and MeeGo Touch styles not only modify the theming but they also ensure that your application becomes finger usable and makes use of the default services and resources provided through each framework.
+Maemo 5 and MeeGo Touch styles not only modify the theming but they also ensure that your application becomes finger-usable and makes use of the default services and resources provided through each framework.
 
-Compared to other Qt styles the Maemo 5 and MeeGo Touch styles go way beyond simple widget styling. They have a significant impact on the way dialogs are shown:
+Compared to other Qt styles, the Maemo 5 and MeeGo Touch styles go way beyond simple widget styling. They have a significant impact on the way dialogs are shown:
 
 - The style automatically follows theme changes on Maemo 5 or MeeGo.
 - Feedback and gesture support is automatically added.
-- The virtual keyboard is supported out of the box
-- Menubars are not shown on top of the window or the screen. Instead they are activated via the navigation bar and are provided as finger usable dialogs.
-- Dialogs are always displayed full-width. They cover a significant portion of the screen.
-- Default dialogs (such as the file dialog) are automatically replaced by a Maemo conform replacement.
+- The virtual keyboard is supported out of the box.
+- Menu bars are not shown on top of the window or the screen. Instead, they are activated through the navigation bar and provided as finger-usable dialogs.
+- Dialogs are always displayed in their full width. They cover a significant portion of the screen.
+- Default dialogs (such as the file dialogue) are automatically replaced withMaemo equivalents.
 - The style provides kinetic scrolling for lists and scroll areas.
-- Scroll bars are only provided as indicators and only appear during scrolling.
-- The style provides orientation change support.
+- Scroll bars are only provided as indicators and appear during scrolling.
+- The style supports change in orientation.
 
 
-In Qt the style can be changed via the command line:
+In Qt, you can change the style from the command line:
 
 \code
 yourapp -style maemo5
@@ -54,106 +53,105 @@ or
 yourapp -style meegotouch
 \endcode
 
-Again note that the Maemo 5 style is only available as a part of the special Qt version that comes with Maemo 5 support. While the MeeGo Touch style is provided via the libmeegotouch framework.
-On both Maemo 5 and MeeGo Touch platform the platform style is used by default for plain Qt applications.
+Note: The Maemo 5 style is only available as a part of the special Qt version that comes with Maemo 5 support, while the MeeGo Touch style is provided by the libmeegotouch framework.
+On both Maemo 5 and MeeGo Touch platforms, the platform style is used by default for plain Qt applications.
 
-If you want to change this style to a different style then you can either do this via the \c -style command line parameter or in your source code via the \c QStyle API. However in general this is not recommended since the default styles provided with Qt are not finger usable.
+You can change the style either with the \c -style command line parameter or in your source code with the \c QStyle API. However, it is not generally recommended since the default styles provided with Qt are not finger-usable.
 
 
 \section  usability  Achieving a good user experience
 
-The user interface of the Maemo and MeeGo platform is optimized for the specific requirements of the device and for the needs of your target audience. This results in a user interface that is significantly different from the desktop paradigm.
-
-Taking a look at your plain Qt application there are in general two scenarios for deployment:
-
-- You're developing a true crossplatform plain Qt application. Your application uses the very same source code to cover all platforms.
-- Or you're working on a plain Qt application that is specifically optimized for use on the Maemo or MeeGo platform (or on mobile devices in general).
+The user interface of the Maemo and MeeGo platform is optimised for the specific requirements of the device and the needs of your target audience. This results in a user interface that is significantly different from the desktop paradigm.
 
-In either case the resulting user experience will most likely not match the quality of a true MeeGo Touch application. Nevertheless there's a set of recommendations we can provide. These recommendations can help you to come at least close and achieve a reasonable good user experience for your application:
+The deployment scenario for a plain Qt application is generally one of the following:
 
+- You are developing a true cross-platform plain Qt application. Your application uses the same source code to cover all platforms.
+- You are working on a plain Qt application that is specifically optimised for use on the Maemo or MeeGo platform (or on mobile devices in general).
 
-\subsection taskoriented Create a user interface that is tailored to the user's workflow
+In both cases, it is most likely that the resulting user experience does not match the quality of a true MeeGo Touch application. Follow the recommendations below to improve the user experience provided by your application.
 
-First and foremost the user interface of Maemo or MeeGo applications is much more simplistic than a typical desktop application. This is due to the obvious limitations in terms of screen size. Due to these constrains the author of a mobile application needs to have a good understanding about the tasks that a user has got to perform. This will help to come up with a user interface that doesn't get in the way of the user and is easy to use.
+\subsection taskoriented Creating a workflow-driven user interface
 
-So if your application has been originally developed for the desktop then you should reconsider the user interface: Often enough desktop applications are unnecessarily cluttered with lots of controls. Such a "heavy" UI does not only exceed the space that is available on the mobile platform. It also typically overwhelms novice users on the desktop.
-So "streamlining" the UI will not only help you to create a good user experience on the mobile platform. It also has the benefit that your application will be easier to use on the desktop as well.
-"Streamlining" doesn't necessarily mean that you need to remove functionality. Often enough it means that you rearrange your UI so that it is more task driven and follows the actual workflow of the user.
+First and foremost, the user interface of Maemo or MeeGo applications is much simpler than a typical desktop application. This is due to the obvious limitations in terms of screen size. Due to these constraints, the application developer must understand the tasks performed by a user. This helps you create a user interface that does not get in the way of the user and is easy to use.
 
+If your application has been originally developed for the desktop, reconsider the user interface. Desktop applications are often unnecessarily cluttered with controls. An over-loaded UI does not only exceed the space that is available on the mobile platform, but also typically overwhelms novice users on the desktop.
+Streamlining the UI helps you create a good user experience on the mobile platform and makes your application easier to use on the desktop as well.
+Streamlining does not necessarily mean that you need to remove functionality, often you just need to rearrange your UI so that it is more task-driven and follows the actual workflow of the user.
 
 \subsection sizeindependent Make your application independent of resolution and available size
 
-The N900 running Maemo is small device. MeeGo Touch will support a range of devices with different screen sizes.
-So it's important that despite the high resolution it's possible to easily recognize all visual parts of the UI from a reasonable distance.
-For normal ready-made QWidgets (like \c QPushButton, \c QMenu, etc.) the style will take care of this automatically.
-Note that for the styling of widgets we use the properties defined in the MeeGo Touch CSS. Therefore in some cases (like for fonts and geometries) we don't use the properties provided by Qt itself.
+The N900 running on Maemo is a small device, whereas MeeGo Touch supports a range of devices with different screen sizes.
+Thus, it is important that, despite the high resolution, it is possible to easily recognise all visual parts of the UI from a reasonable distance.
+For normal ready-made QWidgets (such as \c QPushButton, \c QMenu), the style takes care of this automatically.
+Note: The styling of widgets is carried out according to the properties defined in the MeeGo Touch CSS. Therefore, in some cases (such as with fonts and geometries), the properties provided by Qt itself are not used.
 
-For custom widgets and views you should avoid hardcoding sizes whenever possible. Instead it's better to
+Whenever possible, instead of hard-coding custom widgets and views:
 
-- either use layouts which grow to the available size
-- or use the dpi information provided by the style to calculate a reasonable physical size for the object that you want to display.
+- Use layouts that can be expanded to the available size.
+- Use the dpi information provided by the style to calculate a reasonable physical size for the displayed object.
 
-Also it needs to be possible to resize the application window and dialogs so that they fit into the space that is horizontally available on the device. On the N900 the width of the display in landscape mode is 800 pixels. So your application needs to fit into this minimum screen width. Of course you should also consider lengthy translations when designing the UI of your application.
+It also needs to be possible to resize the application window and dialogs so that they fit into the space that is horizontally available on the device. On the N900 the width of the display in landscape mode is 800 pixels. So your application needs to fit into this minimum screen width. When designing the UI of your application, you should also consider that the translated texts may require more space.
 
-Toolbars should only contain the most important features that are necessary for performing tasks. Ideally the whole toolbar should fit completely onto the screen.
+Tool bars should only contain the most important features that are necessary for performing tasks. Ideally, the whole tool bar should fit completely onto the screen.
 
 
-\subsection fingerusable Ensure that your application stays finger usable
+\subsection fingerusable Ensure that your application stays finger-usable
 
-The MeeGo Touch framework allows navigation via the touch of your fingers.
-This means that you need to think carefully about the size of custom widgets. But it also means that all available functionality needs to be accessible via a "left mouse button click" or gestures.
-In general there are a few common pitfalls which result from the faulty assumption that the user is using a mouse pointer:
+The MeeGo Touch Framework allows users to navigate by using their fingers.
+This means that you need to think carefully about the size of custom widgets and ensure that all functionalities are accessible with a left-click or gestures.
+There are some common pitfalls resulting from the faulty assumption that the user is using a mouse pointer. To avoid these:
 
-- Double click should be avoided.
-- Context menus (which usually get invoked via a right mouse button click) are available via tap&hold interaction and should not be used for primary interactions.
+- Double-click should be avoided.
+- Context menus (which are usually invoked with a right-click) are available through tap and hold interaction and should not be used for primary interactions.
 - Dragging operations are not supported typically as they conflict with panning.
-- Touch displays don't support "hovering". So mouse hovering should be avoided as the only way to accessing functionality provided by the application.
-- Both frameworks switch off the cursor ("mouse pointer") of the application. So your application should be usable even if the cursor isn't visible on the screen.
-- There is no concept such as a visible widget focus rect. So you application needs to be intuitively usable without those.
-- Don't use your own styling on QWidgets. This means not setting a custom style to the widget, using CSS for the widget or even manipulating the widget's palette. This might be ignored by the Meegotouch Qt style or even break the styling up to making the widget unusable.
+- Touch displays do not support "hovering". Thus, avoid mouse hovering as the only way to access a functionality provided by the application.
+- Both frameworks switch off the cursor ("mouse pointer") of the application. So your application should be usable even if the cursor is not visible on the screen.
+- Since there is no such concept as a visible widget focus rectangle, your application needs to be intuitively usable without them.
+- Do not use your own styling on QWidgets. This means that you should not set a custom style to a widget, use CSS for a widget, or even manipulate a widget's palette. Your own styling may be ignored by the MeeGo Touch Qt style or even break the styling and make the widget unusable.
 
 
 \section avoid Things to avoid
 
 \subsection avoidWidgets Avoid fancy widgets
 
-There are a few classes which don't get styled in the MeeGo Touch style or look out of place. Please try to avoid these:
+There are a few classes which are either not styled by the MeeGo Touch style or are otherwise inconsistent. Try to avoid the following:
 
 - \c QDial
 - \c QLCDNumber
 - \c QMdiArea, \c QMdiSubWindow (as well as the whole MDI concept)
 - \c QSplitter
-- \c QSystemTrayIcon (since Maemo doesn't support the system tray)
+- \c QSystemTrayIcon (since Maemo does not support the system tray)
 - \c QToolBox
 - \c QToolTip
 
 \subsection avoidClever Avoid overly clever UI design
 
-Furthermore there are a few more things you should avoid:
+Avoid too complex UI design by following these guidelines: 
 
-- You should avoid hardcoding sizes and colors
-- Avoid complex layouts
-- Don't display multiple windows at once. Use a set of modal dialogs instead which appear in the order of the work flow.
-- Kinetic scrolling is provided by the Maemo styles already. So in order to avoid clashes you shouldn't provide your own custom kinetic scrolling implementation for listviews and scrollareas.
-- Don't use \c QObject::disconnect() to disconnect all signals from a widget and don't disconnect any signals from any widget, which were not connected by yourself.
-- Don't remove any eventFilter classes from any widgets you didn't install by yourself.
-- Avoid setting widget flags manually. Especially flags that affect the painting may cause screwed up results.
+- Do not hardcode sizes and colours.
+- Avoid complex layouts.
+- Do not display multiple windows at once. Instead, use a set of modal dialogs which appear in the order of the workflow.
+- Do not provide your own custom kinetic scrolling implementation for list views and scroll areas. Kinetic scrolling is provided by the platform styles already and custom implementation may cause clashes. 
+- Do not use \c QObject::disconnect() to disconnect all widget signals.
+- Do not disconnect any widget signals that you have not connected yourself.
+- Do not remove any eventFilter classes from widgets that you did not install yourself.
+- Do not set widget flags manually. Especially flags that affect the painting may cause invalid results.
 
-There are also some non-standard practices that don't prevent the style from working, but should be considered when the style delivers unexpected results:
+There are also some non-standard practices that do not prevent the style from working. However, if the style delivers unexpected results, take these issues into account:
 
-- Qt untypical behavior of your application may cause problems, e.g. setting modal flag on a QWidget and then showing it with \c QWidget::show().
-- Custom widgets can't be fully adopted by the style and will be treated as blanc QWidgets. Their background may be removed and due to the widget will not be scaled, it may be unusable on the device's display. If this is the case then you might want to use the \c NoDuiStyle dynamic property as described above.
+- If the behaviour of your application is untypical of Qt, this may cause problems. For example, if the application sets a modal flag on a QWidget and then shows it with \c QWidget::show().
+- Custom widgets cannot be fully adopted by the style and are treated as blank QWidgets. Since the widget background may be removed and, due to the widget, may not be scaled, it may be unusable on the device's display. If this is the case, you can use the \c NoDuiStyle dynamic property as described above.
 
 \subsection avoidTimer Keep the battery in mind
 
-Power saving is especially important for applications that are running on a mobile platform:
+Power saving is especially important for applications that run on a mobile platform:
 
-- Avoid having instances of \c QTimer running permanently in your application. \c QTimer will repeatedly wake up your CPU. Therefore you should keep the use of \c QTimer low.
+- Avoid instances of \c QTimer running permanently in your application. \c QTimer repeatedly wakes up your CPU. Therefore you should keep the use of \c QTimer low.
 
 
 \section maemo5widgets Maemo 5 widgets
 
-There are a few widgets which are specific for the Maemo 5 platform
+The following widgets are specific for the Maemo 5 platform:
 
 - \c QMaemo5AbstractPickSelector
 - \c QMaemo5DatePickSelector
@@ -164,31 +162,31 @@ There are a few widgets which are specific for the Maemo 5 platform
 - \c QMaemo5TimePickSelector
 - \c QMaemo5ValueButton
 
-Use of these widgets is discouraged since they will most likely not be part of the MeeGo Touch platform.
+It is not recommended that you use these widgets since it is most likely that they will not be included in the MeeGo Touch platform.
 
 
 \section API MeeGo Touch Qt style API
 
-There is an API to influence the style on MeeGo Touch. This is done via setting dynamic propertys and using litteral strings because we don't wan't to need to include any headers from MeeGo Touch or even link against any Meegotouch library, to keep the plain Qt application independent from the target platform.
+The MeeGo Touch Qt style API determines the style on MeeGo Touch. The style is set with dynamic properties and literal strings to avoid headers from MeeGo Touch or linking against any MeeGo Touch library. Thus, the plain Qt application is independent of the target platform.
 
-If you want to disable styling for your own custom widget then you can do this via the dynamic property \c NoMStyle. For a custom widget instance "mywidget" it would look like this:
+To disable styling for your own custom widget, use the dynamic property \c NoMStyle. For a custom widget instance "mywidget", it would be:
 
 \code
     mywidget->setProperty("NoMStyle", true);
 \endcode
 
-Doing this should only be done if the style renders a certain custom widget unusable. In practice this should stay the rare exception.
-Note: This only disables styling for this particular widget. It does NOT affect children of "mywidget"!
+Disable styling only if the style renders a certain custom widget unusable, which is very rare in practice.
+Note: This only disables styling for this particular widget. It does not affect the children of "mywidget".
 
-If you run into real problems with the style or if you want to completely disable the meegotouch qt style for your application then you can set the dynamic property also directly for QApplication:
+If you run into problems with the style or want to completely disable the MeeGo Touch Qt style for your application, you can also set the dynamic property directly for QApplication:
 
 \code
     qApp->setProperty("NoMStyle", true);
 \endcode
 
-With the MeeGo Touch Qt style you can also disable some elements, added by the style, e.g. the statusbar or the navigation bar.
+With the MeeGo Touch Qt style you can also disable some elements that are added by the style, for example, the status bar or the navigation bar.
 
-Disabling the statusbar:
+Disabling the status bar:
 \code
     qApp->setProperty("NoMStatusBar", true);
 \endcode
@@ -198,9 +196,9 @@ Disabling the navigation bar:
     qApp->setProperty("NoMNavigationBar", true);
 \endcode
 
-When disabling the navigation bar your application doesn't have close and minimize buttons anymore, so the developer has to care for closing and minimizing the application himself.
+When disabling the navigation bar, your application does not display the Close and Minimise buttons anymore. Thus, the developer needs to close and minimise the application.
 
-The style also provides a basic API for supporting orientation changes on the device. For most QWidget based Qt applications it's difficult to implement an orientation change, but for some cases, e.g. QML or QGraphicsView based applications it can be useful. Therefore the orientation change support of the style is opt-in which means the application needs to tell the style whether it would like to support the orientation change.
+The style also provides a basic API for supporting orientation changes on the device. For most QWidget-based Qt applications it is difficult to implement an orientation change, but for some cases, such as QML- or QGraphicsView-based applications, it can be useful. Therefore the orientation change support of the style is opt-in which means the application needs to tell the style whether it would like to support the orientation change.
 Note: The orientation change support only adjusts the window decorations to the new orientation. You have to take care of rotating the application's content yourself!
 
 You can activate the orientation change for your application like this:
@@ -219,29 +217,29 @@ additionally you can always ask the style about its current orientation by calli
     QMetaObject::invokeMethod(style(), "orientation", Q_RETURN_ARG(int, orientation));
 \endcode
 
-You can also look at qtstyleorientation demo application which shortly demonstrates how orientation change works.
+You can also look at the qtstyleorientation demo application which shortly demonstrates how orientation change works.
 
 The orientation change support is not fully implemented yet. It rotates the statusbar and the navigation bar, but menus and dialogs are not getting rotated yet.
 
 
-Here are a few screen shots comparing the very same view of the same application on both maemo plattforms:
+The following figures illustrate the same view of an application on both supported platforms:
 
-\image html qtstyleexample-pizza-freemantle.png "Example application on Maemo 5 (Freemantle)"
+\image html qtstyleexample-pizza-freemantle.png "Example application on Maemo 5 (Fremantle)"
 
 \image html qtstyleexample-pizza-harmattan.png "Example application on MeeGo"
 
 
-\section  limitations Limitations of the Qt support compared to native MeeGo Touch applications
+\section  limitations Limitations of Qt support compared to native MeeGo Touch applications
 
-Since MeeGo Touch and its widgets are based on \c QGraphicsView there are a few things that can't be emulated for plain \c QWidget based widgets. So these are features of MeeGo Touch which can not be supported by the maemo styles:
+Since MeeGo Touch and its widgets are based on \c QGraphicsView, some features cannot be emulated for plain \c QWidget-based widgets. The following MeeGo Touch features cannot be supported by the Maemo styles:
 
-- Orientation change for ready-made \c QWidgets (not possible on MeeGo). Orientation change notification for custom widgets can be accessed via the Qt Mobility framework.
+- Orientation change for ready-made \c QWidgets (not possible on MeeGo). Orientation change notification for custom widgets can be accessed through the Qt Mobility framework.
 - Ready-made MeeGo Touch widget animations and effects (except for some common ones)
 
 
-\section knownissues Known issues and pit falls
+\section knownissues Known issues and common problems
 
-- Be careful with top level widgets: The style takes care of window management. To accomplish this all top-level windows get reparented into a new layout. This breaks part of Qt's API promise: Windows that are created by the application developer can't later on be indentified or accessed via methods such as \c QWidget::window() or \c QWidget::activeWindow().
+- Be careful with top-level widgets: The style takes care of window management. To accomplish, this all top-level windows are reparented into a new layout. This does not fully comply with the Qt's API promise, since windows created by the application developer cannot be identified or accessed later on with methods such as \c QWidget::window() or \c QWidget::activeWindow().
 
-- "Stacked Windows": At this point the concept of "stacked windows" is not supported.
+- "Stacked windows": At this point the concept of "stacked windows" is not supported.
 */
diff --git a/doc/src/prestart.dox b/doc/src/prestart.dox
index 4545ed54..640726cf 100644
--- a/doc/src/prestart.dox
+++ b/doc/src/prestart.dox
@@ -1,19 +1,19 @@
-/*! \page prestart How to write prestartable and lazily shutdownable applications
+/*! \page prestart Writing prestartable and lazy shutdown applications
 
-A prestarted (or lazily shutdowned) application can show its window almost without a delay when getting released from the prestarted state. MeeGo Touch supports prestarting and lazy shutdown
-of application services, that is, applications that are started by
+An application that has been prestarted (or lazily shut down) can show its window almost without 
+a delay when it is released from the prestarted state. MeeGo Touch supports prestarting and lazy 
+shutdown of application services, that is, applications that are started by
 calling \c launch() (or some other application-specific method) in their
 D-Bus interface.
 
 Prestarted applications are started to a special \b prestarted \b
-state during boot by a daemon called \b Applifed. In that state they are running
-in the background in their mainloop but not showing nor doing anything. If
-application gets terminated, Applifed re-prestarts it automatically.
+state during boot by a daemon called \b Applifed. In that state, they are running
+in the background in their mainloop but do not show or do anything. If an
+application gets terminated, Applifed prestarts it again automatically.
 
-Lazy shutdown allows an application to enter the \b prestarted \b
-state instead of terminating when closed by the user. This makes the next
-application startup very fast. Automatically prestarted applications
-can use lazy shutdown as well.
+When the user closes an application, lazy shutdown allows an application to enter the \b prestarted \b
+state instead of terminating it. This allows the next application to start up very quickly. 
+Automatically prestarted applications can use lazy shutdown as well.
 
  
 \section terminology Terminology
@@ -27,17 +27,16 @@ can use lazy shutdown as well.
   method in the D-Bus interface.
 
 - \b Prestarted \b state - the state where an application waits for
-  launching. In user point of view the application is not running, but
+  launching. From the user's point of view, the application is not running, but
   it can be started up (switched to the running state) much faster
-  than executing it from scratch. Attempts to show a window in this
+  than if it is executed from scratch. Attempts to show a window in this
   state are suppressed.
 
 - \b Prestart \b mode - the property of an application that defines
-  what happens to the application when it is closed. If not set,
+  what happens to the application when it is closed. If it is not set, the
   application does not support prestarting.
 
-- \b Running \b state - the state where an application is running in
-  the user point of view.
+- \b Running \b state - the state when an application is running (from the user's point of view).
 
 - \b TerminateOnClose and \b TerminateOnCloseMultiWindow- prestart
   modes in which an application process is terminated when the
@@ -49,9 +48,9 @@ can use lazy shutdown as well.
 
 If an application supports prestarting, it must set the prestart mode
 with \c MApplication::setPrestartMode(), regardless of the
-commandline parameters and before using any other parts of the
-prestarting API. A recommended place to do this is during or right
-after instantiating the \c MApplication class.
+command line parameters, before using any other parts of the
+prestarting API. It is recommended to do this during or immediately after instantiating 
+the \c MApplication class.
 
 Example:
 
@@ -83,7 +82,7 @@ $ ./example -prestart &
 An application enters the prestarted state if it is started with the
 \c -prestart commandline argument \b and it sets the prestart mode
 before showing any windows. If either one of these conditions does not
-hold, the application will enter to the running state.
+hold, the application enters the running state.
 
 The \c MApplicationWindow::show() method can be called even if the
 application is in the prestarted state. The window will not become
@@ -96,12 +95,13 @@ application is currently in the prestarted state.
 \section launching Releasing application from the prestarted state
 
 If the \c launch() method in MApplication's D-Bus interface is called
-(because of user tapping the application icon, for instance) and the
+(for instance, when the user taps the application icon) and the
 application is in the prestarted state, the application is released
 from the prestarted state and allowed to continue to the running
-state. Make sure that the application registers exactly the same D-Bus service that is defined in the corresponding .service file. Contradictory services may lead to longer startup times.
+state. Make sure that the application registers exactly the same D-Bus service that is defined in 
+the corresponding .service file. Contradictory services may lead to longer start-up times.
 
-The default launch from the application grid can be simulated, for example, like this:
+The default launch from the application grid can be simulated. For example:
 
 \code
 $ dbus-send --dest=com.nokia.example --print-reply --type="method_call" /org/maemo/m com.nokia.MApplicationIf.launch
@@ -113,18 +113,17 @@ The application can also be released from the prestarted state in the code by ca
 The application can react to the launch by connecting the \c
 MApplication::prestartReleased() signal, or by overriding
 MApplication::releasePrestart() handler. The default handler shows
-the active application window of a single-window application, if there
-is such a thing.
+the active window of a single-window application, if one exists.
 
-For multiwindow applications the default handler does nothing. They
-must explicitely release the application from the prestarted by
+For multi-window applications, the default handler does nothing. They
+must explicitly release the application from the prestarted state by
 calling \c MApplication::setPrestarted(false) and show the window
 after that. 
 
 
 \section lazyshutdown Returning to the prestarted state
 
-An application returns from the running state to the prestarted state
+An application returns from running to prestarted state
 if its prestarted mode is set to \c M::LazyShutdown or \c
 M::LazyShutdownMultiWindow and its last window is closed.
 
@@ -134,14 +133,14 @@ overriding the \c MApplication::restorePrestart() event handler.
 The default implementation of \c MApplication::restorePrestart() hides all the open windows.
 
 The application can also return to the prestarted state in the code by calling
-\c MApplication::setPrestarted(true). This is will effectively call the 
+\c MApplication::setPrestarted(true). This effectively calls the 
 \c MApplication::restorePrestart() event handler if one of the lazy shutdown
 modes is set. 
 
 
 \section automaticprestart Prestarting during boot and enabling lazy shutdown
 
-In order to enable lazy shutdown of the application or make the
+To enable lazy shutdown of the application or make the
 application prestartable during device boot, \c -prestart must be
 added to the \b .service \b-file of the application:
 
@@ -151,41 +150,39 @@ Name=com.nokia.example
 Exec=/usr/bin/example -prestart
 \endcode
 
-Note: modifying the service file will not cause starting up and prestarting the
-application at boot, it only makes it possible.
+Note: The above modification enables starting up and prestarting the 
+application. It does not cause the application to start up or prestart at boot. 
 
 If \b Applifed is used for prestarting applications at boot, its configuration file is located in \c
 /etc/prestart. This file contains the names of the prestartable D-Bus services and the
-prestarting priority among some other things, like CPU-load thresholds.
+prestarting priority among other things, such as CPU-load thresholds.
 
-Boot time prestart configuration is typically part of
-platform-specific configurations, and is \b not provided in application
-packages.
+Boot time prestart configuration is typically part of the platform-specific configurations, and 
+is \b not provided in application packages.
 
 
 \section killing Sudden deaths in the prestarted state
 
 Applications in the prestarted state never interact with the user.
-Neither should they take care of any critical tasks, because whether
-or not the applications will be prestarted at all is up to the
-configuration politics.
+They should not take care of any critical tasks, since configuration politics determine whether
+or not the applications is prestarted at all. Thus, the applications in the prestarted state are ideal candidates for 
+suspending and  killing when the system resources run low. Therefore, application developers must 
+be aware that an application in the prestarted state may be killed with KILL signal at any time 
+without any warning.
 
-These facts make the applications in the prestarted state as number
-one candidates for suspending and killing when the system resources
-run low. Therefore, application developers must be aware that an
-application in the prestarted state may be killed with KILL signal at
-any time without any warning.
 
-
-\section multiwindow Prestarting multiwindow applications
+\section multiwindow Prestarting multi-window applications
 
 Multi-window applications can be prestarted by using
-LazyShutdownMultiWindow and TerminateOnCloseMultiWindow modes. The
-difference to the single-window applications is that no window is
-shown by default when the launch() method is called from the D-Bus
-interface. The window should be shown by the code that handles the
-D-Bus call, and the code should release the application from the
-prestarted state before that. See the following example:
+LazyShutdownMultiWindow and TerminateOnCloseMultiWindow modes. As opposed to single-window 
+applications, no window is shown by default when the launch() method is called from the D-Bus
+interface. The window is shown as follows:
+
+1. The code releases the application from the prestarted state. 
+
+2. The code that handles the D-Bus call shows the window.
+
+See the following example:
 
 \code
 void MultiWindowApplication::activateWindow(int index)
@@ -213,11 +210,9 @@ void MultiWindowApplication::activateWindow(int index)
 }
 \endcode
 
-A multi-window application enters the prestarted state when all of its
-windows are closed. The cleanup for the closed windows can be done, for
-instance, on the closeEvent handler of each window, or on restoring
-the prestarted state when all windows are closed.
-
+A multi-window application enters the prestarted state when all its
+windows are closed. Closed windows can be cleaned up, for instance, by the closeEvent handler of 
+each window, or when restoring the prestarted state if all windows are closed.
 
 \section windowclose Controlling window closing on lazy shutdown
 
@@ -226,10 +221,8 @@ mode. On LazyShutdown and LazyShutdownMultiWindow windows are hidden
 by default. On TerminateOnClose and TerminateOnCloseMultWindow windows
 are really closed, just like when application has not been prestarted.
 
-The default closing behavior can changed by overriding the closeEvent
-handler of the window and using \c
-MWindow::setCloseOnLazyShutdown. This is demonstrated in the
-following example.
+To change the default closing behaviour, override the closeEvent handler of the window and use \c
+MWindow::setCloseOnLazyShutdown. See the following example:
 
 \code
 #include <MApplication>
@@ -299,15 +292,13 @@ int main(int argc, char **argv)
 \endcode
 
 
-\section example Example on using handlers
+\section example Example of using handlers
 
-The following example presents a skeleton of a single window
-application. If application is started with the \c -prestart
-commandline argument, it connects the signal about restoring the
-prestarted state to the slot that resets the page displayed on the
-window. Note that showing and hiding the window does not require any
-actions from the application developer in the single window
-applications (see the default event handlers above).
+The following example shows a skeleton of a single-window application. If \c -prestart command line 
+argument starts an application, it connects the signal for restoring the prestarted state to the 
+slot that resets the page displayed in the window.  Note: Showing and hiding the window does not require any 
+actions from the application developer in single-window applications. For more information, see the 
+default event handlers above.
 
 
 \code
diff --git a/doc/src/responsivewindow.dox b/doc/src/responsivewindow.dox
index e41a6998..113eb98d 100644
--- a/doc/src/responsivewindow.dox
+++ b/doc/src/responsivewindow.dox
@@ -1,57 +1,51 @@
-/*! \page responsivewindow How to show a responsive window fast in a MeeGo Touch application
-
-In some cases with heavy applications using the 
-\subpage launcher "application launcher" will not give fast enough 
-startup for the application. This being the case, the developer 
-should consider implementing his application so that loading 
-the GUI content of the application happens in several phases. The 
-main point of this approach is to show the window with a minimal 
-content as fast as possible when
-the user starts the application, and after that update the application
-page with the "real" content. This will make the startup experience
-for the user more pleasant than waiting longer for the complete GUI content 
-appearing to the screen. 
-
-The purpose of this document is to give some ideas on how the 
-developer can implement this feature in his application using 
-means provided by Qt and how to avoid general problems with this
-kind of approach. 
+/*! \page responsivewindow Showing a responsive window quickly in a MeeGo Touch application
+
+Sometimes when heavy applications use the \subpage launcher, the "application 
+launcher" does not start up the application fast enough. In these cases, 
+consider implementing your application so that loading the GUI content of the 
+application occurs in several phases. This approach enables the application 
+to show the window with minimal content as fast as possible when the user 
+starts the application, and, after that, update the application page 
+with the "real" content. This makes the start-up experience more pleasant 
+for the users, since they do not have to wait until the complete GUI content 
+appears on the screen. 
+
+This section describes how to implement this feature in your application using 
+means provided by Qt and how to avoid general problems with this approach. 
 
 \section implementation Implementation basics
 
-The basic implementation goes simply like this:
+To implement this feature:
 
     \li Make the application use MBooster (see \ref launcher) 
 
-    \li Show a temporary application page while loading/building up the actual content of the GUI on the background Note!!: This won't work without the application launcher and booster, because then the launch would be too slow.
+    \li Show a temporary application page while loading/building up the actual content of the GUI on the background. Note: This does not work without the application launcher and booster because the launch would be too slow.
 
-In practice this can be achieved by creating the initial GUI content 
-inside the constructor of the application's main page and defining 
-a new public slot createFinalContent() which takes care of loading
-the actual content of the application's GUI:
+In practice, you need to create the initial GUI content inside the constructor 
+of the application's main page and define a new public slot createFinalContent() 
+which loads the actual content of the application's GUI:
 
 \code
 MainPage::MainPage() 
 {
-    // Create the initial content in here
+    // Create the initial content here
 
 }
 
 void MainPage::createFinalContent()
 {
 
-    // Create the actual content in here
+    // Create the actual content here
 
 }
 \endcode
 
-In application's main() one can now create the main page (with the
-initial content inside it) and make it appear. After this we can
+In application's main() you can now create the main page (with the
+initial content inside it) and display it. After this, 
 connect MApplicationWindow::displayEntered() to 
-MainPage::createFinalContent(), which will take care of creating
-the actual GUI of the application. This connection ensures that we 
-will start loading the actual GUI content right after the initial content
-has become visible on the display:
+MainPage::createFinalContent(), which creates the actual GUI of the application. 
+This connection ensures that the loading of the actual GUI content starts immediately 
+after the initial content has become visible on the display:
 
 
 \code
@@ -70,10 +64,8 @@ M_EXPORT int main(int argc, char **argv)
 }
 \endcode
 
-The final thing to remember is to disconnect the signal as a first 
-step inside function MainPage::createFinalContent(). This 
-ensures that the slot is called only once when starting the
-application:
+Finally, disconnect the signal as a first step inside function MainPage::createFinalContent(). 
+This ensures that the slot is called only once when starting the application:
 
 \code
 void MainPage::createFinalContent()
@@ -86,59 +78,54 @@ void MainPage::createFinalContent()
 
 \section problems Possible problems
 
-\subsection dlopen Minimize the time used for loading shared libraries
+\subsection dlopen Minimising loading time for shared libraries
 
-Shared libraries are loaded during the application start-up and 
-that can take a lot of time. This time it's unfortunately affecting also the time
-which is taken before any initial content can be shown.
+Shared libraries are loaded during the application start-up, which can take a lot of time. 
+Unfortunately, the loading time also causes delay before any initial content can be shown.
 
-To minimize this time it is important:
+To minimise the loading time:
 
-   \li Avoid any unnecessary linking of shared libraries to the application code. It is also recommended to consider to use <a href="http://www.gentoo.org/proj/en/qa/asneeded.xml"> --as-needed </a> parameter for the linker, to avoid these kind of problems.
+   \li Avoid any unnecessary linking of shared libraries to the application code. It is also recommended to consider using <a href="http://www.gentoo.org/proj/en/qa/asneeded.xml"> --as-needed </a> parameter for the linker.
 
-   \li If possible, load the plugin-libraries after the initial content of the GUI is shown.
+   \li If possible, load the plug-in libraries after the initial content of the GUI is shown.
 
    \li If own shared libraries are used, the loading time of those should be optimized
 
-Here is a few tips how to optimize loading time for your own shared
+Here are some tips for optimising loading time for your own shared
 libraries:
-   \li Don't do heavy initializations at the loading phase.
+   \li Do not perform heavy initialisations during the loading phase.
    \li All static constructors are executed when loading the library. Therefore, try to avoid the use of static constructors when implementing the library.
-   \li Execute the initializations by calling separate method after the application window is shown.
+   \li Execute the initialisations by calling a separate method after the application window is shown.
 
 
-\subsection responsive Keeping the GUI Responsive
+\subsection responsive Keeping the GUI responsive
 
-When performing heavy operations in meegotouch applications it is 
+When performing heavy operations in MeeGo Touch applications, it is 
 important that the GUI of the application still remains responsive. 
 This is a common issue in Qt applications and there are different 
-ways to avoid it, depending on the situation. 
+ways to maintain the responsiveness, depending on the situation. 
 
 Loading the actual application content after
-showing the initial GUI might be a time consuming operation. Usually 
+showing the initial GUI can be a time-consuming operation. Usually 
 the initial content itself does not contain interactive items which 
-should be responsive, but still we should take into account, 
-for example, that the user may want to close the application during the 
-time the real content is being built up. 
+should be responsive. However, take into account that the user 
+may, for example, want to close the application while the real content is being built up. 
 
-As said, this a known issue in Qt application development in general and 
-there is very good 
+Since this a known issue in Qt application development in general, there is very good 
 <a href="http://doc.trolltech.com/qq/qq27-responsive-guis.html">
-documentation </a> available which presents a range of 
-possible solutions to avoid freezing the GUI during long operations. 
-In this documentation we have picked up two possible ways to 
-go around this problem when implementing the GUI content loading in phases.
+documentation </a> available which presents a range of possible solutions to avoid 
+freezing the GUI during long operations. This section presents two possible ways to 
+avoid this problem when implementing the GUI content loading in phases.
 
-\subsubsection processevents Process events manually
+\subsubsection processevents Processing events manually
 
-The simplest solution to avoid freezing is to handle pending events from 
-time to time manually while creating the content of the actual application
-page. In practice this means calling MApplication::processEvents()
-periodically whenever possible. 
+The simplest solution to avoid freezing is handling pending events manually from 
+time to time while creating the content of the actual application
+page. In practice, this means calling MApplication::processEvents() periodically 
+whenever possible. 
 
-For example, if you need to load and scale all the
-images in the /root directory and show them in the actual application page
-you keep GUI responsive as follows:
+For example, if you need to load and scale all the images in the /root directory and 
+show them in the actual application page, keep the GUI responsive as follows:
 
 \code 
 QDir dir("/root");
@@ -150,25 +137,25 @@ Q_FOREACH(QString file, dir.entryList(QStringList("*.jpg"))) {
 \endcode
 
 There are still some problems in this approach. Events are handled
-only after loading and scaling each individual image. In practice 
+only after loading and scaling each individual image. In practice, 
 this means that GUI stays quite responsive as long as loading and
-scaling one image is not taking too much time. When trying this example
-with very large size image files, these operations can take even several
+scaling one image does not take too much time. When trying this example
+with very large image files, the operations can take even several
 seconds per image. This means that if the user tries to close the application
-during that time, the GUI responses to the close event only after a delay 
-of several seconds. Therefore, in general the "processEvents()"-approach
-should be used only in cases where several short operations are executed.
+during that time, the GUI responds to the close event only after a delay 
+of several seconds. Therefore, in general the "processEvents()" approach
+should be used only in cases when several short operations are executed.
 
 \subsubsection threadin Building the actual GUI in a separate thread
 
-Another way to keep things responsive is to build the actual content inside
+Another way to keep responsiveness is to build the actual content inside
 a separate thread. The main advantage of this approach is that the event
-loop stays running virtually without any interrupts and thus the
-GUI stays also responsive for user actions. The main disadvantage is that
+loop stays running virtually without any interrupts and, thus, the
+GUI also stays responsive for user actions. The main disadvantage is that
 this approach is a bit more complex to implement than simply calling processEvents() here and there.
 
-Here is the same image loader example, but now with a worker class
-inherited from QThread taking care of the heavy stuff:
+Here is the same image loader example with a worker class
+inherited from QThread which takes care of the heavy stuff:
 
 \code
 Worker::Worker(MApplicationWindow * window) :
@@ -205,7 +192,7 @@ This signal connection is now needed in main():
     app->connect(worker, SIGNAL(finished()), mainPage, SLOT(showContent()));
 \endcode
 
-Now, in main page's showContent() we can just use the already loaded and
+Now, in main page's showContent() just use the already loaded and
 scaled images from Worker class:
 
 \code
@@ -226,14 +213,14 @@ void MainPage::showContent()
 
 \endcode
 
-Note that MImageWidget's cannot be created in the worker thread due to
-thread safety issues. Qt would throw some warnings if tried.
+Note: MImageWidget's cannot be created in the worker thread due to
+thread safety issues. If you try this, Qt throws some warnings.
 
 \subsection rotation Rotation
 
-As with the normal application GUI's, it is important to notice possible
-screen orientation changes when the window is visible. In practice this
-means that we have to define both landscape and portrait policies for the
+As with the normal application GUI, it is important to notice possible
+screen orientation changes when the window is visible. In practice, this
+means that you have to define both landscape and portrait policies for the
 initial GUI layout.
 
 */
diff --git a/doc/src/rotation.dox b/doc/src/rotation.dox
index 61227d5d..0d148f91 100644
--- a/doc/src/rotation.dox
+++ b/doc/src/rotation.dox
@@ -1,18 +1,18 @@
-/*! \page rotation Screen Rotation
+/*! \page rotation Screen rotation
 
-MeeGo Touch applications can be used in both landscape and portrait orientations. Applications can be rotated to four different orientation angles: 0 (landscape), 90 (portrait), 180 (landscape) and 270 degrees clockwise (portrait). For details on coordinate systems and what those angles are relative to please read \subpage sceneandscenewindows.
+MeeGo Touch applications can be used in both landscape and portrait orientations. You can rotate applications to four different orientation angles: 0 (landscape), 90 (portrait), 180 (landscape) and 270 degrees clockwise (portrait). For more information on coordinate systems and related angles, see \subpage sceneandscenewindows.
 
-By default, MeeGo Touch applications will automatically rotate to the appropriate orientation angle when needed. It just works.
+By default, MeeGo Touch applications automatically rotate to the appropriate orientation angle when needed. It just works.
 
 \section rotation_getset Checking or setting the current orientation
 
-In some applications it might be needed to get or manually set the current orientation.
-To accomplish that the following methods and signals are provided by MWindow:
+Some applications may need to allow checking or manually setting the current orientation. MWindow provides 
+the following methods and signals for this purpose:
 
 <table>
   <tr>
     <td>MWindow::orientation()</td>
-    <td>Returns the current orientation (i.e. portrait or landscape) of the GUI.</td>
+    <td>Returns the current orientation (portrait or landscape) of the GUI.</td>
   </tr>
   <tr>
     <td>MWindow::setLandscapeOrientation()</td>
@@ -38,7 +38,8 @@ To accomplish that the following methods and signals are provided by MWindow:
   </tr>
 </table>
 
-You can also deal with orientation angles directly, although you should take into consideration which angles make sense for the host device. More on that later.
+You can also deal with orientation angles directly. However, take into consideration which angles 
+are relevant for the host device. For more information, see the following sections.
 
 <table>
   <tr>
@@ -58,29 +59,34 @@ You can also deal with orientation angles directly, although you should take int
   </tr>
 </table>
 
-MSceneManager provides a similar API. If an MWindow has a scene manager, all the methods and sinals mentioned above will simply mirror those of its scene manager. That's because what's actually rotating is not the MWindow itself but the items (i.e., scene windows) in the scene visualized by it. For more information please read \subpage sceneandscenewindows.
+MSceneManager provides a similar API. If an MWindow has a scene manager, all the methods and signals mentioned above simply mirror those of its scene manager. This is due to the fact that MWindow itself is not rotated but the items (in other words, scene windows) in the displayed scene. For more information, see \subpage sceneandscenewindows.
 
-When the orientation changes a MOrientationChangeEvent event is also sent to all affected widgets. To easily handle this event in your widget you can reimplement the following method:
+When the orientation changes, an MOrientationChangeEvent event is also sent to all affected widgets. To easily handle this event in your widget, reimplement the following method:
 
 MWidget::orientationChangeEvent(MOrientationChangeEvent *event)
 
 \section rotation_supportedangles Orientation angles supported by the host device
 
-Different devices allow a diferent number of orientation angles. A mobile phone, for instance, might support angle 270 but not 90, therefore probably meaning that 270 is the portrait orientation angle that puts its earpiece on top of the GUI and its mouthpiece below the GUI.
+Different devices allow different orientation angles. A mobile phone, for instance, can support the angle 270 but not 90, which probably means that 270 is the portrait orientation angle that puts its earpiece on top of the GUI and its mouthpiece below the GUI.
 
-If a device has a hardware keyboard, its set of allowed angles will also depend on whether this keyboard is open or not. For example: some device might support angles 0 and 270 when its hardware keyboard is closed but only angle 0 when it is open.
+If a device has a hardware keyboard, the allowed angles also depend on whether the keyboard is open 
+or not. For example, a device supports angles 0 and 270 when its hardware keyboard is closed and 
+only angle 0 when it is open.
 
-To check whether a given orientation angle is supported by the host device (i.e., makes sense for it) you can use the following method:
+To check whether a given orientation angle is supported by the host device (and is relevant for it),
+you can use the following method:
 
 bool MDeviceProfile::orientationAngleIsSupported(M::OrientationAngle angle, bool isKeyboardOpen);
 
-\section rotation_deviceorientation Following (or not) the orientation of the host device
+\section rotation_deviceorientation Overriding automatic rotation
 
-When the orientation of a device changes (within its set of supported orientation angles), the orientation of its MeeGo Touch application will automatically follow accordingly.
+When the orientation of a device changes (within its set of supported orientation angles), the 
+orientation is automatically applied to its MeeGo Touch application.
 
-An application can override those automatic rotations by locking its GUI into a specific angle or orientation. You can lock the GUI into any orientation angle regardless of whether it's allowed by the device. Note that jutst setting a orientation (using a method such as MWindow::setOrientationAngle()) without locking it won't stop your GUI from following the device orientation when it changes afterwards.
+You can override automatic rotation by locking the GUI of the application to a specific angle 
+or orientation. You can lock the GUI to any orientation angle whether it is supported by the device or not. Note that if you just set an orientation (using a method such as MWindow::setOrientationAngle()) without locking it, the orientation of your GUI changes according to the device orientation.
 
-For locking the GUI into a given orientation (portrait or landscape), the following methods are available:
+To lock the GUI to a specific orientation (portrait or landscape), use the following methods:
 
 <table>
   <tr>
@@ -90,8 +96,8 @@ For locking the GUI into a given orientation (portrait or landscape), the follow
   <tr>
     <td>MWindow::unlockOrientation()</td>
     <td>
-        Unlocks the GUI into from its current orientation. Changes in the device
-        orientation after this point will be followed by the GUI.
+        Unlocks the GUI from its current orientation. If the device
+        orientation changes after this point, the orientation of the GUI changes accordingly.
     </td>
   </tr>
   <tr>
@@ -100,22 +106,22 @@ For locking the GUI into a given orientation (portrait or landscape), the follow
   </tr>
   <tr>
     <td>MWindow::setOrientationLocked()</td>
-    <td>Locks the GUI into its current orientation or unlocks the GUI from it.</td>
+    <td>Locks the GUI into its current orientation or unlocks the GUI orientation.</td>
   </tr>
 </table>
 
-It's also possible to be more restrictive and lock the GUI into a specific angle.
+To be more restrictive and lock the GUI to a specific angle:
 
 <table>
   <tr>
     <td>MWindow::lockOrientationAngle()</td>
-    <td>Locks the GUI into its current orientation angle.</td>
+    <td>Locks the GUI to its current orientation angle.</td>
   </tr>
   <tr>
     <td>MWindow::unlockOrientationAngle()</td>
     <td>
-        Unlocks the GUI into from its current orientation angle. Changes in the device
-        orientation after this point will be followed by the GUI.
+        Unlocks the GUI from its current orientation angle. If the device
+        orientation changes after this point, the orientation of the GUI changes accordingly.
     </td>
   </tr>
   <tr>
@@ -124,27 +130,32 @@ It's also possible to be more restrictive and lock the GUI into a specific angle
   </tr>
   <tr>
     <td>MWindow::setOrientationAngleLocked()</td>
-    <td>Locks the GUI into its current orientation angle or unlocks the GUI from it.</td>
+    <td>Locks the GUI to its current orientation angle or unlocks the GUI orientation angle.</td>
   </tr>
 </table>
 
-Locking the orientation is discouraged as it breaks expected behavior and usability (e.g. "why this app doesn't rotate like the others?") and limits the flexibility of your GUI, although it can be useful and valid for applications whose GUI is meant to be used (or makes sense) only in one specific orientation or angle.
+Locking the orientation is not recommended because it breaks expected behaviour and usability. For 
+example, users might wonder why the application does not rotate like the others. It also limits the 
+flexibility of your GUI. However, locking the orientation of the GUI can be useful and valid if it 
+is intended to be used in only one specific orientation or angle.
 
-\section rotation_stepbystep A rotation animation, step-by-step
+\section rotation_stepbystep Creating rotation animation
 
--# MSceneManager::setOrientationAngle() gets called (e.g., due to a change in the device's orientation angle)
+To create a rotation animation, do the following:
+
+-# MSceneManager::setOrientationAngle() is called (for example, due to a change in the device's orientation angle)
 -# MSceneManager starts a rotation animation
--# At some point during the rotation animation MSceneManager does, in the following order:
+-# During the rotation animation MSceneManager does the following:
     -# Emission of MSceneManager::orientationAboutToChange().
     -# Sending of MOrientationChangeEvent to all widgets in the scene.
-        - Will cause MWidgetView::applyStyle() to be called on views of all affected widgets.
-        - Will cause MLayouts to switch to the layout policy of the new orientation.
+        - Causes MWidgetView::applyStyle() to be called on views of all affected widgets.
+        - Causes MLayouts to switch to the layout policy of the new orientation.
     -# Resizing and repositioning of all scene windows to the new orientation.
     -# Emission of MSceneManager::orientationChanged() (if applicable).
-        - Will trigger the emission of MWindow::orientationChanged()
+        - Triggers the emission of MWindow::orientationChanged()
     -# Emission of MSceneManager::orientationAngleChanged().
-        - Will trigger the emission of MWindow::orientationAngleChanged()
--# MSceneManager's rotation animation finishes. MSceneManager::orientationChangeFinished() is emited.
-    - Will trigger the emission of MWindow::orientationChangeFinished()
+        - Triggers the emission of MWindow::orientationAngleChanged()
+-# MSceneManager's rotation animation finishes. MSceneManager::orientationChangeFinished() is emitted.
+    - Triggers the emission of MWindow::orientationChangeFinished()
 
 */
diff --git a/doc/src/sceneandscenewindows.dox b/doc/src/sceneandscenewindows.dox
index 92aa4990..af1117ff 100644
--- a/doc/src/sceneandscenewindows.dox
+++ b/doc/src/sceneandscenewindows.dox
@@ -1,19 +1,19 @@
-/*! \page sceneandscenewindows The scene and its scene windows
+/*! \page sceneandscenewindows Scene and scene windows
 
-All graphical items of a MeeGo Touch application are positioned in a Cartesian plane which we call "scene". The scene is represented by the <code>MScene</code> class. The X-axis grows rightwards and the Y-axis downwards.
+All graphical items of a MeeGo Touch application are positioned in a Cartesian plane called a "scene". The scene is represented by the <code>MScene</code> class. The X-axis expands from left to right and the Y-axis expands from top to bottom.
 
-What is seen through an MApplicationWindow is just a rectangular area of that scene. This rectangle has its top left corner on (0, 0). Its width and height are equivalent to the device's horizontal and vertical pixel resolution, respectively.
+An MApplicationWindow only shows a rectangular area of the scene. The rectangle has its top left corner at "0, 0". Its width and height are equivalent to the horizontal and vertical pixel resolution of the device, respectively.
 
 \image html "scene and view.png" "MScene and MApplicationWindow"
 
-Scene windows are the graphical items that comprise the high-level layout of a MeeGo Touch application. Virtually all graphical items in a standard MeeGo Touch application are held in a scene window of some type. They are represented by the <code>MSceneWindow</code> class. Scene windows in a scene are analogous to top level windows in a traditional desktop windowing system.
+Scene windows are the graphical items that comprise the high-level layout of a MeeGo Touch application. Virtually all graphical items in a standard MeeGo Touch application are held in a scene window. They are represented by the <code>MSceneWindow</code> class. Scene windows in a scene correspond to top-level windows in a traditional desktop window system.
 
 \image html "scene windows.png" "The basic scene windows of a MeeGo Touch application"
 
-The stacking order (Z-value) and geometry (position and size) of scene windows are controlled by a scene manager (<code>MSceneManager</code>). When the device orientation changes, the scene manager orchestrates the rotation and repositioning of all its scene windows. In order to properly rotate the UI, the scene manager have all its scene windows inside a graphical item called <i>root element</i> (meaning that it is the parent of all scene windows in the scene graph), which gets rotated instead of the scene windows themselves. This means that scene windows are positioned in the root element's coordinate system, not in scene coordinates. MeeGo Touch defines four possible rotation angles for its UI: 0, 90, 180 and 270 degrees (clockwise).
+A scene manager (<code>MSceneManager</code>) controls the stacking order (Z-value) and geometry (position and size) of scene windows. When the device orientation changes, the scene manager rotates and repositions all the scene windows. In order to properly rotate the UI, all the scene windows of the scene manager are located inside a graphical item called <i>root element</i> (which means that it is the parent of all scene windows in the scene graph). The root element is rotated instead of the scene windows themselves. This means that scene windows are positioned in the root element's coordinate system, not in scene coordinates. MeeGo Touch defines four possible rotation angles for its UI: 0, 90, 180 and 270 degrees (clockwise).
 
 \image html "root element and scene window.png" "A scene window at different orientation angles"
 
-<code>MApplicationWindow</code> creates its own <code>MScene</code> and <code>MSceneManager</code>. It also automatically populates the scene with all the scene windows that comprise a standard MeeGo Touch GUI, such as a status bar, navigation bar, home button panel, etc.
+<code>MApplicationWindow</code> creates its own <code>MScene</code> and <code>MSceneManager</code>. It also automatically populates the scene with all the scene windows that comprise a standard MeeGo Touch GUI, such as a status bar, navigation bar, home button panel, and so one.
 
 */
diff --git a/doc/src/servicefw.dox b/doc/src/servicefw.dox
index e759d190..28e73c44 100644
--- a/doc/src/servicefw.dox
+++ b/doc/src/servicefw.dox
@@ -1,58 +1,58 @@
-/*! \page servicefw Service Framework
+/*! \page servicefw Service framework
 
 \section intro_sec Introduction
 
-The service framework is an IPC mechanism that allows applications to simply either use or serve an interface. For the purposes of this documentation, the interface user process is referred to as 'user' and the interface provider process is referred to as the 'provider'.
+The service framework is an IPC mechanism that simply allows applications to either use or serve an interface. In this section, the interface user process is referred to as 'user' and the interface provider process is referred to as the 'provider'.
 
-The objectives of the service framework are :
+The service framework:
 <ol>
-<li> to provide an IPC mechanism that is simple to use,</li>
-<li> to ensure there is no run time binary dependancy between the service user and provider,</li>
-<li> to allow the user to just use an interface and not worry about the logic of choosing or connecting to an interface,</li>
-<li> to allow the user to query a list of providers and choose one of them.</li>
+<li> Provides an IPC mechanism that is simple to use.</li>
+<li> Ensures there is no run-time binary dependency between the service user and provider.</li>
+<li> Allows the user to use an interface without worrying about the logic of choosing or connecting to an interface.</li>
+<li> Allows the user to query a list of providers and choose one of them.</li>
 </ol>
 
-    \image html sfw_mechanism.png "The basic service framework mechanism."
+    \image html sfw_mechanism.png "Basic service framework mechanism"
 
 The above diagram shows what happens behind the scenes when a Service User (SU) uses an Interface (IF).
 
 <ol>
-<li> The service user instantiates an interface which causes the interface to ask the servicemapper (a dedicated dbus service) for the name of a service provider that implements that interface.
-<li> The service mapper has been maintaining a map of services<->interfaces (by watching the dbus services directory, typically /usr/share/dbus-1/services) and has rules to determine which one to pick. It picks a service and returns the name to the interface in SU.
-<li> The interface in SU then makes a regular dbus connection to the given service name and calls the appropriate method.
+<li> The service user instantiates an interface which causes the interface to ask the service mapper (a dedicated dbus service) for the name of a service provider that implements that interface.
+<li> The service mapper maintains a map of services and interfaces (by watching the dbus services directory, typically /usr/share/dbus-1/services) and has rules for choosing a service. It selects a service and returns the name to the interface in SU.
+<li> The interface in SU makes a regular dbus connection to the given service name and calls the appropriate method.
 </ol>
 
-The service mapper will send signals to the corresponding SU interfaces to inform them when there is a new SP for the IF, or if there are no more SPs for the IF. The application should connect to the signals in the IF in order to tell when these events occur and to take appropriate action. For example, a gallery application may wish to allow a user to send a photo via email and it might listen to the 'no more SP for IF' signal in order to tell when to disable the option.
+The service mapper sends signals to the corresponding SU interfaces to inform them when there is a new SP for the IF, or if there are no more SPs for the IF. The application should connect to the signals in the IF in order to tell when these events occur and to take appropriate action. For example, if a gallery application allows a user to send a photo by e-mail, it listens to the 'no more SP for IF' signal to know when to disable the option.
 
-\section whywhen Typical usecases for the Service Framework
+\section whywhen Typical use cases for the service framework
 
 <ol>
 <li> Launch/Display a certain view of an application from another application or applet in experience canvas
 <li> Get a list/thumbnails of available video content on the device
-<li> Launch a web-browser displaying a certain web-page
+<li> Launch a web browser displaying a certain web page
 <li> Choose/Display some image from available content
 <li> Show recent contacts
-<li> Show calendar appointments for 13. friday 2042
+<li> Show calendar appointments for Friday, 13 June 2042
 </ol>
 
-Service Framework should not be used for generic IPC communication purposes or, for example, communication between applets. This should be done using other means like using a data backend that provides notifications of changes to values like MValueSpace.
+Do not use the service framework for generic IPC communication purposes or, for example, for communication between applets. For this purpose, use other means, such as a data backend that provides notifications of changes to values such as MValueSpace.
 
-\section usage Using the Service Framework
+\section usage Using the service framework
 
 \subsection usagesp As a Service Provider (SP)
 
-Two things are required of the developer of an SP :
+The following are required of an SP developer:
 
 <dl>
 <dt>Binary</dt>
-<dd>This is the binary that will be launched (if it is not already running) when a Service User application tries to connect to the service.</dd>
+<dd>Launched (if it is not already running) when a Service User application tries to connect to the service.</dd>
 <dt>Interface</dt>
-<dd>This consists of the files needed by the developer of a Service User application. It consists of :
+<dd>Consists of the files needed by the developer of a Service User application. It consists of:
 <ul>
 <li>mservicefwbaseif.h/cpp files that are common to all interfaces.<br/>
-The mservicefwbaseif.h file is part of the libmeegotouch-dev package and the mservicefwbaseif.cpp is compiled into libmeegotouch itself and so is part of the libmeegotouchcore0 package.</li>
+The mservicefwbaseif.h file is part of the libmeegotouch-dev package. The mservicefwbaseif.cpp is compiled into libmeegotouch itself and is, thus, part of the libmeegotouchcore0 package.</li>
 <li>XML file, header files, a library and a .service file for the interface being supplied.<br/>
-The interface specific header files should be made part of the maemo-interfaces-dev package along with the interface's XML file, and the corresponding cpp files compiled into interface specific libs that are made part of the maemo-interfaces package. The .service file should also be made part of the maemo-interfaces package.</li>
+The interface-specific header files must be included in the maemo-interfaces-dev package along with the interface's XML file. The corresponding cpp files must be compiled into interface-specific libs included in the maemo-interfaces package. The .service file should also be included in the maemo-interfaces package.</li>
 </dd>
 </ul>
 </dl>
@@ -62,8 +62,8 @@ The interface specific header files should be made part of the maemo-interfaces-
 <ul>
 <li>Create an XML file that defines the interface.</li>
 
-      If you wish a method to be chained to the current application, you can add a 'chainTask="true"' attribute to the method tag.
-      If you wish a method to be asynchronous, you can add an 'asyncTask="true"' attribute to the method tag. Note that such methods must not have any 'out' parameters.
+      To chain a method to the current application, add a 'chainTask="true"' attribute to the method tag.
+      To create an asynchronous method, add an 'asyncTask="true"' attribute to the method tag. Note: The asynchronous methods must not have any 'out' parameters.
 
       For example:
 
@@ -82,7 +82,7 @@ The interface specific header files should be made part of the maemo-interfaces-
 </node>
 \endverbatim
 
-<li>Run the m-servicefwgen tool to generate the adaptor h and cpp files, for example : </li>
+<li>Run the m-servicefwgen tool to generate the adaptor h and cpp files. For example: </li>
 
 \verbatim
 m-servicefwgen -a com.nokia.TextProcessorInterface
@@ -90,10 +90,10 @@ m-servicefwgen -a com.nokia.TextProcessorInterface
 
 <li>Change your code.</li>
 
-      There are three steps that are illustrated in the following code snippet :
+      The following code snippet illustrates three steps:
 
 \verbatim
-// 1. Make an instance of the class that has methods that implement the interface functionality
+// 1. Make an instance of the class that has methods which implement the interface functionality
 MyService myService;
 
 // 2. Make an adaptor to link the dbus methods with the methods in myService
@@ -113,11 +113,11 @@ return app.exec();
 
 \subsubsection interface Interface
 
-There are three steps to defining an interface.
+To define an interface:
 
 <ul>
 <li>Create an XML file defining the interface - this is the same XML file as described above.</li>
-<li>Run the m-servicefwgen tool to generate the proxy header and cpp files, and the wrapper header file. For example : </li>
+<li>Run the m-servicefwgen tool to generate the proxy header, cpp files, and the wrapper header file. For example : </li>
 
 \verbatim
 m-servicefwgen -p com.nokia.TextProcessorInterface
@@ -126,9 +126,9 @@ m-servicefwgen -p com.nokia.TextProcessorInterface
 <li>You need to generate the service libraries.</li>
 </ul>
 
-The above files should be made part of the maemo-interfaces package. The library should be in maemo-interfaces, and the header and xml files should be in maemo-interfaces-dev.
+The above files should be included in the maemo-interfaces package. The library should be in maemo-interfaces, and the header and XML files should be in maemo-interfaces-dev.
 
-Documentation for an interface and its methods can be added between '<doc>' and '</doc>' tags, as follows :
+Documentation for an interface and its methods can be added between '<doc>' and '</doc>' tags. For example:
 
 \verbatim
     <interface name="com.nokia.someserviceinterface">
@@ -152,7 +152,7 @@ Documentation for an interface and its methods can be added between '<doc>' and
 
 <ol>
 <li>Install the libmeegotouch-dev and libmeegotouch-bin debian packages. This gives you the service mapper dbus daemon, headers, and lib.</li>
-<li>Install the maemo-meegotouch-interfaces-dev package (incudes the proxy header and lib, and the wrapper header file).</li>
+<li>Install the maemo-meegotouch-interfaces-dev package (includes the proxy header and lib, and the wrapper header file).</li>
 <li>Add -lmeegotouch and -l<interfacename> to LIBS in your project file.</li>
 <li>In your source, include the interface header file and create an instance of the interface and call method serviceName() to get the provider for the interface.</li>
 <li>Check to see if the service was found OK using the 'isValid()' method.</li>
@@ -162,15 +162,15 @@ Documentation for an interface and its methods can be added between '<doc>' and
 
 \section demos Demos and example code
 
-In libmeegotouch/demos/servicefw/ there is example code showing three service providers and a service user. The com.nokia.textprocessor and org.maemo.textprocessor services both implement the same interface - com.nokia.TextProcessorInterface. There are two services so that we are able to remove services and see that the service user is switched from one service to another/etc. There is one script tools/m-servicefwgen, which is used to generate the source files that are used to define the interface to the service user. To run this demo :</li>
+In libmeegotouch/demos/servicefw/ there is example code showing three service providers and a service user. The com.nokia.textprocessor and org.maemo.textprocessor services both implement the same interface - com.nokia.TextProcessorInterface. There are two services that enable you to remove services and see that the service user is switched from one service to another, and so on. There is one script tools/m-servicefwgen, which is used to generate the source files used to define the interface to the service user. To run this demo:</li>
 <ul>
 <li>cd libmeegotouch</li>
 <li>qmake && make && make install (or at least do a make install in the mservicemapper directory)</li>
 <li>cd demos/servicefw</li>
-<li>pushd misc; sudo ./INSTALL; popd (this will install the relevant dbus service files into /usr/share/dbus-1/services)</li>
+<li>pushd misc; sudo ./INSTALL; popd (this installs the relevant dbus service files into /usr/share/dbus-1/services)</li>
 <li>LD_LIBRARY_PATH=lib bin/user</li>
-<li>This will open a small window that will allow you to enter text which will be sent through the interface to a service which will return the reversed text.</li>
+<li>This opens a small window that allows you to enter text which is sent through the interface to a service which returns the reversed text.</li>
 </ul>
-In this demo, you can remove the various service files from /usr/share/dbus-1/services to simulate the service being removed (and added again) and see that the service user application 'does the right thing'.</li>
+In this demo, you can remove the various service files from /usr/share/dbus-1/services to simulate the service being removed (and added again) and see that the service user application functions correctly.</li>
 
 */
diff --git a/doc/src/styling.dox b/doc/src/styling.dox
index f683b8a7..42c42db0 100644
--- a/doc/src/styling.dox
+++ b/doc/src/styling.dox
@@ -1,38 +1,38 @@
-/*! \page styling Overview
+/*! \page styling Styling
 
-MeeGo Touch provides a powerful styling engine for applications to customize their look & feel. It provides following functionality to application development:
 
-    \li Style sheets & style sheet parser
-    \li Type safe styling parameters
-    \li Automatic tools to populate the instantiated styles according to definitions in style sheets
-    \li Simple and robust interface for application developers to access the styling parameters
-    \li Flexible but simple way to define and use style parameters using inheritance, modes etc. 
+MeeGo Touch provides a powerful styling engine for applications to customise their look and feel. As an application developer, you can:
 
-\section responsibilities People involved & their responsibilities 
+    \li Use style sheets and style sheet parser.
+    \li Use type-safe styling parameters.
+    \li Use automatic tools to populate the instantiated styles according to definitions in style sheets.
+    \li Use simple and robust interface for application developers to access the styling parameters.
+    \li Define and use style parameters in a simple and flexible way, for instance, by using inheritance and modes.
 
-    Styling involves several people to work tightly together. This is important since otherwise there is no 
-    way to ensure that the style is working properly and the way it is implemented is consistent in all 
-    the projects.
+\section responsibilities Roles and responsibilities 
 
-    - UI Designer
-        - Has an idea how the widget should look and how it needs to be styled.
-        - Provides design for the styling and answers to questions about it.
-    - Software Developer
+    Styling involves several people who work tightly together. Otherwise, there is no way to ensure 
+	that the style works properly and its implementation is consistent in all projects.
+
+    - UI designer
+        - Knows how the widget should look and how it needs to be styled.
+        - Provides design for the styling and answers questions about it.
+    - Software developer
         - Implements the stylable object (widget, layout, etc..).
-        - Creates enablers for the styling on the source code level.
-        - Creates initial version of the stylesheet for testing.
+        - Creates enablers for the styling at the source code level.
+        - Creates initial version of the style sheet for testing.
     - Tester
-        - Tests that the styling is actually working according to the design.
-    - UI Designer / Theme Implementor
+        - Tests that the styling matches the design.
+    - UI designer / Theme implementer
         - Updates the style sheet to contain proper values for the application.
-        - Ensures that the final version of the style sheet that ships out with the product matches
+        - Ensures that the final version of the style sheet accompanying the product matches
           the requirements.
 
-\section links Documentation links 
+\section links For more information on styling, see: 
     \li \subpage styling_concepts "Basic concepts of styling"
-    \li \subpage styling_features "Features"
-    \li \subpage styling_support "Styling support for applications & external libraries"
-    \li \subpage styling_stylesheets "Stylesheet syntax reference & examples"
-    \li \subpage styling_in_code "Architecture & code examples"
+    \li \subpage styling_features "Styling features"
+    \li \subpage styling_support "Theming support for applications and external libraries"
+    \li \subpage styling_stylesheets "Styling with style sheets"
+    \li \subpage styling_in_code "Styling in application code"
 
 */
diff --git a/doc/src/styling_concepts.dox b/doc/src/styling_concepts.dox
index 1d81d944..5deb4784 100644
--- a/doc/src/styling_concepts.dox
+++ b/doc/src/styling_concepts.dox
@@ -1,28 +1,32 @@
 /*! \page styling_concepts Basic concepts
 
-    A style in MeeGo Touch contains key-value pairs ("attributes"), that are used when the stylable object
-    is drawn to the screen. A style attribute has always three properties:
-    Type, name, and value. As an example, a good style attribute could be something like pen color, margin or
+    A style in MeeGo Touch contains key-value pairs ("attributes") that are used when the stylable object
+    is drawn to the screen. A style attribute always has the following properties: 
+	- type 
+	- name
+	- value
+
+	For example, a good style attribute could be something like pen colour, margin, or
     text font. Style attributes are defined in the source code and their values are defined in the style
     sheet(s).
 
     MeeGo Touch styles can be inherited. It means that the derived style can introduce new style
     attributes on top of the 'base' style and it can even override the values for the attributes that are
-    being derived. This behavior is defined on the source code level by software designers.
+    being derived. This behaviour is defined at the source code level by software designers.
 
-    Responsibilities of the style system components:
-    - Theme provides styles for the stylable object
-    - Style contains a set of style attributes
-    - Style gets initialized from the style sheet(s)
+    Style system components have the following responsibilities:
+    - Theme provides styles for the stylable object.
+    - Style contains a set of style attributes.
+    - Style is initialised from the style sheet(s).
 
-    \image html style_basic.png "The basic building blocks of the styling system."
+    \image html style_basic.png "Basic building blocks of the styling system"
 
-    Styling in MeeGo Touch always includes at least three steps, these are:
+    Styling in MeeGo Touch always includes at least the following steps:
     - Defining the style in the source code
     - Defining values for the attributes in the style sheet(s)
     - Accessing the defined style values from within the source code
 
-    These steps ensure that you will have a configurable style for your stylable object. It provides
+    These steps ensure that you have a configurable style for your stylable object. It provides
     a type-safe class for application developers to access the style, while allowing the UI designers to
     configure the styling as needed through the style sheets. This is the basic form of styling in MeeGo Touch.
 */
diff --git a/doc/src/styling_features.dox b/doc/src/styling_features.dox
index 814e9e5e..b7d87b5a 100644
--- a/doc/src/styling_features.dox
+++ b/doc/src/styling_features.dox
@@ -1,49 +1,46 @@
-/*! \page styling_features Features
+/*! \page styling_features Styling features
 
     \section parent_child_relationship_based_styling Styling based on parent-child relationship
         In MeeGo Touch the style of a widget may have a different style depending on the type of its parent widget.
-        For example, you can define a custom style for a button in the view menu, making it look different just
-        because the type of its parent is a view menu.
+        For example, you can define a custom style for a button in the view menu, so that it it looks different if its parent is a view menu.
 
         Consider using the parent-child relationship in styling, when you want to have a custom style for the
-        widgets inside another widget. Good examples are the children of composite widgets, like
-        the label and background of a list item, the button and text in a view menu, etc.
+        widgets inside another widget. Good examples are the children of composite widgets, such as
+        the label and background of a list item, and button and text in a view menu.
 
     \section mode_based_styling Styling based on mode
         It is also possible to style objects depending of their internal 'mode'. The word mode is actually quite
-        flexible in this concept, meaning that modes can be introduced by the programmer as needed.
+        flexible in this concept, meaning that modes can be introduced by the developer as needed.
         Whenever your stylable object changes its state, it notifies the style about it and the style attribute
         values are then automatically changed to reflect the new state.
-        For example, a list item could have different modes based on its selection state; having black text on
-        white background in unselected state and white text on blue background when being selected.
+        For example, a list item can have different modes based on its selection state; there is black text on a
+        white background when the item has not been selected and white text on a blue background when the item is selected.
 
-        \image html mode_style.png "Styling using mode."
+        \image html mode_style.png "Styling using mode"
 
         Consider using the mode in styling, when you have clearly different states for your stylable object.
-        Good examples are states like: selected/unselected, open/closed, night/day etc.
+        Good examples are states selected/unselected, open/closed, night/day, and so on.
 
     \section objectname_based_styling Styling based on object naming
         Object naming means that you give a name for your stylable object. It allows you to define a custom set
-        of attributes for that specific object in your stylesheet. Basically what happens is that your object is
-        being identified by the system and the custom styling is then being applied to it. The name acts as an
-        identifier for your stylable object.
+        of attributes for that specific object in your style sheet. Basically, your object is identified by the system and the custom styling is then applied to it. The name acts as an identifier for your stylable object.
 
-        \image html named_style.png "Styling using object naming."
+        \image html named_style.png "Styling using object naming"
 
         Use object naming when you need to assign a unique style to a unique object. An example would be individual
         buttons on a dial pad, if each of them has a distinct style. If you have a group of objects that need to
-        be styled in a similiar (but custom) way, consider using another method (like parent-child-relationship)
+        be styled in a similar (but custom) way, consider using another method (like parent-child-relationship)
         for it instead.
 
     \section orientation_based_styling Styling based on device orientation
-        The style system supports styling in both orientations; portrait and landscape. It allows you to
+        The style system supports styling in both portrait and landscape orientation. It allows you to
         have different widget styles for both screen orientations. The style objects are automatically
         updated to reflect the new orientation when the device is rotated by the user.
 
-        \image html orientation_style.png "Styling using orientation."
+        \image html orientation_style.png "Styling using orientation"
 
-        Use the orientation parameter when for example you have some margin and spacing values for landscape rotation
-        and you want to have smaller ones in portrait mode.
+        Use the orientation parameter when, for example, you have some margin and spacing values for landscape rotation
+        and you want to decrease the values in portrait mode.
 
     \section type_based_styling Styling based on type
         \todo documentation missing
diff --git a/doc/src/styling_in_code.dox b/doc/src/styling_in_code.dox
index c59b1952..06191c47 100644
--- a/doc/src/styling_in_code.dox
+++ b/doc/src/styling_in_code.dox
@@ -3,55 +3,54 @@
 \section styling_in_application_code Styling in application code
 
     \subsection architecture Architecture
-        In MeeGo Touch Framework, the theme acts as a base for all the styling. If the theme is changed in
+        In MeeGo Touch Framework, the theme is the basis for all styling. If you change the theme in the 
         runtime, the look and feel for the whole system can radically change. The following figure shows
         the basic building blocks of the MeeGo Touch style system. It also illustrates how the styling is
         integrated with the widgets.
 
-        \image html widgets_style.png "Architecture of the MeeGo Touch styling system."
+        \image html widgets_style.png "Architecture of the MeeGo Touch styling system"
 
     \subsection mtheme MTheme
         All the style objects are used by the theme class. Theme class provides services to create a new style
-        object and to release it. It reference counts all the style objects and provides a cache, which allows
-        multiple widgets to share same style objects, therefore optimizing the speed and memory consumption of
+        object and release it. It reference counts all the style objects and provides a cache, which allows
+        multiple widgets to share same style objects, therefore optimising the speed and memory consumption of
         the system.
 
     \subsection mstylesheetparser MStyleSheetParser
-        This class parses style sheets. It reads stylesheet files and converts them to data
-        structure in memory. It also provides services to dump the whole data structure to disk and to read it
-        back into memory. This is a huge optimization since the whole parsing process can be bypassed after the
-        stylesheet has been processed once.
+        This class parses style sheets. It reads style sheet files and converts them to the data
+        structure in the memory. It also provides services for dumping the whole data structure to disk and reading it
+        back into the memory. This is a huge optimisation since the whole parsing process can be bypassed after the
+        style sheet has been processed once.
 
     \subsection mstylesheet MStyleSheet
         This class provides support for the actual cascading process when the style sheet is being processed
-        runtime. It is responsible of populating the style classes and to handle all the style attributes in a
+        runtime. It is responsible for populating the style classes and handling all the style attributes in a
         type-safe manner.
 
     \subsection mstyle MStyle
         MStyle class is the actual container for all the style attributes. The attributes are stored as Qt
-        properties and they can be therefore accessed easily and also they can be later on animated using
+        properties and they can be therefore accessed easily and animated later on using
         property animators. MStyle is a base class for all the styles.
 
     \subsection style_classes MWidgetStyle, MButtonStyle, MLabelStyle
         These are MStyle-derived classes, providing a set of attributes for the same type of widget.
-        Basically there is one style class per one stylable component in the MeeGo Touch Framework.
+        Basically there is one style class for each stylable component in the MeeGo Touch Framework.
 
     \subsection mstylecontainer MStyleContainer
         MStyleContainer class groups multiple MStyle instances together. It provides services like
-        indicating the mode of the stylable object to the style system; or later on, even animating attribute
+        indicating the mode of the stylable object to the style system or, later on, even animating attribute
         values between different styles. The style is always accessed through the container.
 
     \subsection creating_new_style_class Creating a new style class
-        Creating a new style class is a pretty simple process. Basically what you do is just derive from the style
-        class you want to inherit from and add the attributes you need. In this example, a new style is created for a
-        custom widget, therefore we start by deriving the new style class from the MWidgetStyle class.
+        Creating a new style class is a relatively simple process. Basically, you just derive from the style
+        class that you want to inherit from and add the attributes you need. In this example, since a new style is created for a
+        custom widget, you start by deriving the new style class from the MWidgetStyle class.
 
-        An important thing to note is that when declaring a new style class, either the M_STYLE or M_STYLE_INTERNAL
+        Note: When declaring a new style class, either the M_STYLE or M_STYLE_INTERNAL
         macro needs to be declared inside the class in the header file. Use M_STYLE when you inherit your style
         class from a style class which is defined outside of your library/application. Use M_STYLE_INTERNAL when
         you inherit from a style class which is defined in the same library/application you are working with. The
-        macro will create a private data member to your class, which will later on during the process store the real
-        attribute data of your style class.
+        macro creates a private data member to your class, which stores the real attribute data of your style class later on during the process.
 
         \code
         class MyWidgetStyle : public MWidgetStyle
@@ -62,16 +61,17 @@
         \endcode
 
         \subsection defining_style_attributes Defining attributes for the style
-            Attributes are declared by using the M_STYLE_ATTRIBUTE(type, name, Name) macro. This macro will
-            generate accessor methods to your attribute and it will also create Q_PROPERTY definition for it,
-            making your attribute exist in the Qt's meta object. M_STYLE_ATTRIBUTE has three parameters. The
-            first one is the datatype of the attribute (int, qreal etc..) the other two concentrate on naming
-            of the attribute and accessor methods.
+            Attributes are declared by using the M_STYLE_ATTRIBUTE(type, name, Name) macro. This macro 
+            generates accessor methods to your attribute and it also creates Q_PROPERTY definition for it,
+            making your attribute exist in the Qt's meta object. M_STYLE_ATTRIBUTE has the following parameters:
+            - data type of the attribute (such as int or qreal)
+            - attribute name
+            - accessor method
 
-            The name parameter of the macro will be converted to style sheet-attribute name so that every
-            camelcase letter is converted to dash and lowercase letter (e.g. marginLeft becomes margin-left).
+            The name parameter of the macro is converted to style sheet-attribute name so that every
+            camelcase letter is converted to dash and lower-case letter (for example, marginLeft becomes margin-left).
 
-            Here is an example of our new style class, with two attributes defined:
+            The following example illustrates a new style class with two defined attributes:
             \code
             class MyWidgetStyle : public MWidgetStyle
             {
@@ -82,20 +82,19 @@
             };
             \endcode
 
-            Next step is to create a container class for the style objects of this type. Style container
-            provides access to the actual style data and it also makes it possible to indicate to the style system
-            that your stylable object has changed from one mode into another. Once again there are two macros:
+            Next, you can create a container class for the style objects of this type. Style container
+            provides access to the actual style data and also makes it possible to indicate to the style system
+            that your stylable object has changed from one mode into another. The following macros are available:
 
             - M_STYLE_CONTAINER(style class name)
             - M_STYLE_CONTAINER_INTERNAL(style class name)
 
-            If you used M_STYLE in the style class you must use M_STYLE_CONTAINER in the container class.
-            If you used M_STYLE_INTERNAL in the style class you must use M_STYLE_CONTAINER_INTERNAL in the
-            container class. This macro will automatically generate an accessor operator and reloading of the
-            style data if the mode changes while the application is running. Note that the parameter of the macro
-            needs to be the type of the style class you created above.
+            If you used M_STYLE in the style class, you must use M_STYLE_CONTAINER in the container class.
+            If you used M_STYLE_INTERNAL in the style class, you must use M_STYLE_CONTAINER_INTERNAL in the
+            container class. This macro automatically generates an accessor operator and reloads the
+            style data if the mode changes while the application is running. Note: You must use the type of the style class that you created as the parameter of the macro.
 
-            The style container needs to be inherited from the corresponding container class, here's an example:
+            The following example illustrates how the style container needs to be inherited from the corresponding container class:
             \code
             MyWidgetStyleContainer : public MWidgetStyleContainer
             {
@@ -103,15 +102,15 @@
             };
             \endcode
 
-            \image html style_macros.png "A diagram showing how macros are used in different libraries & executables."
+            \image html style_macros.png "Macros used in different libraries and executables"
 
         \subsection defining_modes_for_style Defining modes for the style
             If you decide to support modes in your style class, those can be defined with the M_STYLE_MODE macro.
-            This macro will expand to a method, which will set the corresponding mode enabled. For example,
-            M_STYLE_MODE(Indexing) will expand to a setModeIndexing() method, which can be called to start
+            This macro expands to a method, which enables the corresponding mode. For example,
+            M_STYLE_MODE(Indexing) expands to a setModeIndexing() method, which can be called to start
             retrieving attribute values from that mode.
 
-            Here's an example to add a few modes to the container
+            The following example illustrates how to add modes to the container:
             \code
             MyWidgetStyleContainer : public MWidgetStyleContainer
             {
@@ -121,14 +120,13 @@
             };
             \endcode
 
-            The new style class is now ready to be configured through the style sheets, see Styling with
-            stylesheets for more details about that subject.
+            The new style class is now ready to be configured through the style sheets. For more information, see Styling with style sheets.
 
         \subsection accessing_style_attributes Accessing the style attributes
         MeeGo Touch provides a simple way to access the style attributes by providing a style instance for the
-        stylable object. This class contains simple accessor methods which allows one to read the values of the
+        stylable object. This class contains simple accessor methods which allow you to read the values of the
         attributes. The name of the accessor method is defined by the second parameter in the M_STYLE_ATTRIBUTE
-        macro. See an example of accessing the style below.
+        macro. The following example illustrates how to access the style:
 
         \code
         // assuming that widget is using MyWidgetStyle
@@ -147,7 +145,7 @@
         \subsection runtime_style_changes Runtime style change for widgets
             When the style changes in runtime, the MWidgetView::applyStyle method will be called. It means
             that the attributes are reloaded with new values and they are ready to be used. This method is
-            virtual and it can be overridden in the derived classes. See the example below.
+            virtual and it can be overridden in the derived classes. See the following example:
 
             \code
             // in MyWidgetView.h
@@ -175,31 +173,33 @@
             \endcode
 
 \section using_helper_tools Using helper tools
-    There are two helper tools which make the creation of new style classes easier. These tools are mgen and
-    mmoc. It is important to note that one doesn't have to use these tools, everything can be done without
+    There are two helper tools which facilitate the creation of new style classes. These tools are mgen and
+    mmoc. It is important to note that you do not have to use these tools, everything can be done without
     them. So if you decide to bypass the toolchain, it means that you have to write all the private classes and
-    attribute accessor methods by yourself. Writing all of those files is a lot of work and you also get the
-    responsibility to maintain all of those files. The toolchain does most of that stuff in compile time, so
-    it is worth having a closer look at it.
+    attribute accessor methods by yourself. Writing all the files requires a lot of work and makes 
+	you responsible for maintaining the files. Since the toolchain carries out most of the work  
+	during the compilation process, you should consider using it.
 
     \subsection mgen mgen
         mgen generates private data classes and their content for all the styles. It also generates the
-        constructor/destructor code to your style class among with all the needed necessary accessor methods.
+        constructor/destructor code to your style class along with all the required accessor methods.
         Everything is generated and compiled during the make process.
 
     \subsection mmoc mmoc
-        mmoc is a pretty simple script. Because Qt's moc doesn't know how to expand macros there needs to be
+        mmoc is a pretty simple script. Because Qt's moc doesn't know how to expand macros, there needs to be
         a way to expand the M_STYLE_ATTRIBUTE macros for it. The mmoc tool expands them to Qt's Moccer so that
-        the Q_PROPERTY macro gets translated by the Qt Moc.
+        the Q_PROPERTY macro is translated by the Qt Moc.
     
-    \image html toolchain.png "Graph showing how mgen & mmoc are integrated into the build process."
+    \image html toolchain.png "Integration of mgen and mmoc into the build process"
     
     \subsection configuring_project_to_use_helper_tools Configuring your project to use helper tools
-        In order to use the helper tools automatically, you need to add CONFIG += meegotouch to your .pro file. In
-        addition, you must declare your model & style header files to be processed by adding them into the
-        MODEL_HEADERS and STYLE_HEADERS. Note that your style & model headers must also exist in the common HEADER
-        section. See the example .pro file below for how to do that.
+        To use the helper tools automatically:
+		
+        1. Add CONFIG += meegotouch to your .pro file. 
+		2. To declare your model and style header files to be processed, add them into the 
+        MODEL_HEADERS and STYLE_HEADERS.
 
+		Note: Your style and model headers must also exist in the common HEADER section, see the following example:
         \code
         TEMPLATE = app
         TARGET = mywidget
@@ -217,19 +217,17 @@
 \section advanced_styling_in_app Advanced styling in application code
 
     \subsection parent_child_relationship_in_app Parent-child relationship in application
-        Using parent-child relationship in styling needs nothing more than assigning a parent to the widget
+        To use parent-child relationship in styling, assign a parent to the widget
         which needs to be styled. This can be achieved by calling QGraphicsItem::setParentItem method for the
-        MWidgetController. After that the system is aware of the widgets parent, therefore being able to
+        MWidgetController. After that, the system is aware of the widget's parent, and is thus able to
         assign a proper style for it.
 
     \subsection mode_in_app Mode in application
         If the state of your stylable changes, you need to inform the styling system about it. This is done
         by calling the corresponding method in the MStyleContainer class. For example, if you have defined
         a mode 'Selected' to your style container class, you can call the setModeSelected() method to enable that
-        kind of styling. The styling system uses the mode as a parameter in MTheme::style calls when it
-        reloads the styles.
-
-        Here's an example:
+       styling. The styling system uses the mode as a parameter in MTheme::style calls when it
+        reloads the styles, see the following example:
         \code
         // assume that this is defined in the MWidgetStyleContainer class
         M_STYLE_MODE(Selected)
@@ -242,13 +240,11 @@
         \endcode
 
     \subsection named_objects_in_app Styling based on object naming
-        By assigning an object name to the stylable object, the system identifies that the object will need
-        unique styling. If this styling is defined in the style sheet, it will be automatically applied by
+        By assigning an object name to the stylable object, the system identifies that the object needs
+        unique styling. If this styling is defined in the style sheet, it is automatically applied by
         the system. The object name is assigned to the stylable object by using the QObject::setObjectName method.
         The styling system uses the object name as a parameter in MTheme::style calls when it reloads the
-        styles.
-
-        Here's an example:
+        styles, see the following example:
         \code
         // Assume that this is created earlier somewhere
         MButton* button;
@@ -258,8 +254,8 @@
         \endcode
 
     \subsection orientation_in_app Orientation in application
-        Style changes & reloading during the device orientation change is a somewhat automatic process, at least
-        for the widgets. Basically all the styles get reloaded automatically and the styling system uses the
+        Style changes and reloading during the device orientation change is a relatively automatic process, at least
+        for the widgets. Basically, all the styles are reloaded automatically and the styling system uses the
         device orientation as a parameter in MTheme::style calls.
 
     \subsection type_in_app Type in application
diff --git a/doc/src/styling_stylesheets.dox b/doc/src/styling_stylesheets.dox
index 8d2b8a5b..7ed1d11e 100644
--- a/doc/src/styling_stylesheets.dox
+++ b/doc/src/styling_stylesheets.dox
@@ -1,25 +1,20 @@
-/*! \page styling_stylesheets Stylesheets
-
-    As stated earlier in this documentation, the application developer adds the style to the system
-    (for e.g. some widget) and a set of attributes are defined for the style. These attributes are defined by
-    UI-Designers and they can be customized using the style sheets. Style sheets provide an easier way to
-    customize the look and feel of the system, without a need to re-compile the system all over again if
-    something needs to be changed. Style sheets are also intuitive and they are simple to use. When the
-    system starts up, the style sheets are loaded and the styles are automatically initialized according
+/*! \page styling_stylesheets Styling with style sheets
+
+    The application developer adds the style to the system (for instance, for a widget) and a set of attributes are defined for the style. These attributes are defined by UI designers, and they can be customised with style sheets. Style sheets provide an easier way to
+    customise the look and feel of the system, without a need to re-compile the system all over again if
+    something needs to be changed. Style sheets are also intuitive and simple to use. When the
+    system starts up, style sheets are loaded and the styles are automatically initialised according
     to the values defined in the style sheets.
 
     \section syntax_reference Syntax reference
-    This section describes the syntax for stylesheet files. The following chapters contain the building blocks
-    for the styleheet definition from top to bottom. Most of the syntax follows the basic CSS rules but there
-    are also some MeeGo-specific additions.
+    This section describes the syntax for style sheet files. The following sections describe the building blocks for the style sheet definition from top to bottom. Most of the syntax follows the basic CSS rules, but there are also some MeeGo-specific additions.
 
         \subsection import_sheet Import
             Syntax: \@import ""; or \@import url("");
 
-            Description: Makes it possible to import other stylesheet files and in this way combine multiple
-            stylesheets as one.
+            Description: Imports additional style sheet files and, in this way, combines multiple style sheets into one.
 
-            Details: All the import statements must reside at the top of the .css file, before any selectors are defined.
+            Details: All the import statements must reside at the top of the CSS file, before any selectors are defined.
 
             \code
             @import "commonstylesheet.css";
@@ -40,12 +35,12 @@
 
             Description: Groups attributes for a defined style
             
-            Details: Selectors group attributes of the same category together. In MeeGo Touch stylesheets, it
-            basically means having one selector for each style class. Selector attributes follow the general
-            inheritance rules, so if you declare base class selectors, their contents will by default, inherit
-            to the subclasses. If you want to break this inheritance chain, you can add a dot character (.) in
+            Details: Selectors group attributes of the same category together. In MeeGo Touch style sheets, it
+            basically means that there is one selector for each style class. Selector attributes follow the general
+            inheritance rules, so if you declare base class selectors, their contents inherit
+            to the subclasses by default. If you want to break this inheritance chain, you can add a dot character (.) in
             front of the class name, meaning that those attributes are not derived to the subclasses but used
-            only for that class. As a general rule, most of the attributes should derive and therefore you
+            only for that class. As a general rule, most of the attributes should derive. Therefore, you
             should consider before using the dot in front of the class name.
 
             \code
@@ -73,8 +68,8 @@
             Application developers define them in the style header file, according to instructions from the UI
             designer.
 
-            The attribute naming between C++ code and stylesheets follows the pattern where camelcase names are
-            converted into lowercase strings with hyphens. See the example below.
+            The attribute naming between C++ code and style sheets follows the pattern where camelcase names are
+            converted into lower-case strings with hyphens. See the example below.
 
             <table border="1" cellpadding="3">
             <tr>
@@ -129,11 +124,11 @@
         \subsection constants Constants
             Syntax: \@const constant-name: constant-value;
 
-            Description: Makes it possible define constant values in stylesheets, avoiding the need to maintain
-            duplicated data that is spread around the stylesheet.
+            Description: Defines constant values in a style sheet, so you do not need to maintain
+            duplicated data that is spread around the style sheet.
 
             Details: Constant variables are defined using a syntax similar to attributes. Constant
-            definitions support the same types and suffices as attributes do. Constants are assigned to
+            definitions support the same types and suffixes as attributes. Constants are assigned to
             attributes using the '$' character as prefix.
 
             \code
@@ -150,18 +145,18 @@
             \endcode
 
 
-    \section advanced_styling_with_stylesheets Advanced styling with stylesheets
+    \section advanced_styling_with_stylesheets Advanced styling with style sheets
 
-        \subsection parent_child_in_stylesheet Parent-child relationship in stylesheet
+        \subsection parent_child_in_stylesheet Parent-child relationship in style sheets
             Syntax: parentclassname styleclassname { }
 
-            Description: Makes it possible to define a set of attributes if the widget's parent is a 
-                         certain widget.
+            Description: Defines a set of attributes for a widget that has a certain widget as a 
+			parent.
 
             Details: The parent is defined using the name of the widget class, not a style class. This is because the look
                      and feel of the parent is not important. It is not possible to add any other parameters to the parent.
                      Note that when styling from libraries, specifying a custom parent class is the only way to affect the
-                     styling of widgets external to the library (i.e. common widgets). See
+                     styling of widgets external to the library, in other words, common widgets. See
                      \ref lib_themefiles "Providing view configuration & stylesheets for the widgets" for details.
 
             \code
@@ -177,10 +172,10 @@
             }
             \endcode
 
-        \subsection mode_in_stylesheet Mode in stylesheets
+        \subsection mode_in_stylesheet Mode in style sheets
             Syntax: styleclassname:mode { }
 
-            Description: Makes it possible to define a set of attributes for a certain mode.
+            Description: Defines a set of attributes for a certain mode.
 
             Details: The mode parameter is separated by a colon and it must be the last one in the selector
                      definition.
@@ -199,21 +194,22 @@
             }
             \endcode
 
-        \subsection object_names_in_stylesheet Object names in stylesheets
+        \subsection object_names_in_stylesheet Object names in style sheets
             Syntax: styleclassname#name { }
 
-            Description: Makes it possible to define a set of attributes for named object.
+            Description: Defines a set of attributes for a named object.
 
-            Details: The name parameter is separated by the '#' character and it must follow the class name and
-            type when defining the selector. The actual name is bound to a widget on source code level by the
-            software developer as instructed by the UI Designer. This allows the person who creates the
-            stylesheet to assign a custom style for the named widget. Consult your UI Designer for the
+            Details: The name parameter is separated by the '#' character, and it must follow the class name and
+            type when defining the selector. The software developer binds the 
+			actual name to the widget at the source-code level according to the instructions from 
+			the UI designer. This allows the person who creates the
+            style sheet to assign a custom style for the named widget. Consult your UI designer for the
             object names in the application you are developing.
 
-            Here are some rules for how the system assigns named attributes:
-            - The system automatically takes care that the named attributes are assigned to objects which are named in a similar way
-            - Attributes that are not named are always assigned to the object, even if a widget has a name
-            - Named attributes always override attributes which are not named
+            The system assigns named attributes as follows:
+            - The system automatically ensures that the named attributes are assigned to objects which are named in a similar way
+            - Unnamed attributes are always assigned to an object, even if a widget has a name
+            - Named attributes always override unnamed attributes
 
             \code
             MyWidgetStyle#fancynamedwidget
@@ -223,12 +219,12 @@
             }
             \endcode
 
-        \subsection orientation_in_stylesheet Orientation in stylesheets
+        \subsection orientation_in_stylesheet Orientation in style sheets
             Syntax: styleclassname.orientation { }
 
-            Description: Makes it possible to define a set of attributes depending on device orientation.
+            Description: Defines a set of attributes depending on the device orientation.
 
-            Details: The orientation parameter is separated by a dot character and it must follow the
+            Details: The orientation parameter is separated by a dot character, and it must follow the
             object name when defining the selector. Two orientations can be defined, "Portrait" and
             "Landscape".
 
@@ -252,11 +248,11 @@
             }
             \endcode
 
-            Here are some rules for how the orientation parameter affects the styling:
-            - The system automatically takes care that you will receive the proper attribute values from correct orientation
-            - If the orientation is not specified for the style, the attributes will be used in both orientations
-            - Style definitions with orientation parameter defined, override the definitions which have no orientation parameter defined
+            The orientation parameter affects styling as follows:
+            - The system automatically ensures that you receive the proper attribute values from correct orientation.
+            - If the orientation is not specified for the style, the attributes are used in both orientations.
+            - If the orientation parameter has been defined for a style definition, it overrides a definition with no defined orientation parameter.
 
-        \subsection type_in_stylesheet Type in stylesheet
+        \subsection type_in_stylesheet Type in style sheets
             \todo add documentation
 */
diff --git a/doc/src/styling_support.dox b/doc/src/styling_support.dox
index bcf404bb..bf8e14a5 100644
--- a/doc/src/styling_support.dox
+++ b/doc/src/styling_support.dox
@@ -1,18 +1,18 @@
-/*! \page styling_support Theming support for applications & external libraries
+/*! \page styling_support Theming support for applications and external libraries
 
 \section applications Theming support for external libraries
     External libraries can enable theming support through the M_LIBRARY macro. This macro creates a static MLibrary object,
-    which gets initialized when the library is loaded. During the construction phase, the MLibrary object registers itself
-    to the MTheme, making the theme aware of the need for theming support for this particular library. Later on when the
-    library gets unloaded, the MLibrary object is destroyed automatically and it unregisters the library from the MTheme.
+    which is initialised when the library is loaded. During the construction phase, the MLibrary object registers itself
+    to the MTheme, making the theme aware of the need for theming support for this particular library. Later on, when the
+    library is unloaded, the MLibrary object is destroyed automatically and it unregisters the library from the MTheme.
 
     Theming support allows a library to:
     - Register widgets, views, styles & animations
-    - Provide view configuration for the widgets, declared in that library
-    - Provide stylesheets for the styles, declared in that library
+    - Provide view configuration for the widgets declared in that library
+    - Provide style sheets for the styles declared in that library
 
-    The registration name of the library will be the build target name, defined in the library .pro file. It is necessary to
-    use CONFIG += meegotouch to enable the functionality described above. Here's a simple example of a library .pro file:
+    The registration name of the library is the build target name defined in the library .pro file. It is necessary to
+    use CONFIG += meegotouch to enable the functionality described above. The following example illustrates a simple library .pro file:
 
     \code
     MGEN_OUTDIR = ./.gen
@@ -52,17 +52,18 @@
 
         Styles can be registered to the system using the M_REGISTER_STYLE(styleclass) macro. It is necessary to register styles
         to the system to be able to provide theming support for them. Note that if you use automatic style class generation through
-        mgen/mmoc, the generated style class will be automatically registered to the system.
+        mgen/mmoc, the generated style class is automatically registered to the system.
+
             Style registration allows the system to:
             - Construct an instance of the style after its type has been resolved from the view class
             - Determine the origin (application or library) for the style
-            - Determine the proper stylesheet(s) for the style class
+            - Determine the proper style sheet(s) for the style class
 
-    \subsection lib_themefiles Providing view configuration & stylesheets for the widgets
-        External libraries can provide stylesheets & view configuration for their own widgets. Stylesheets contain the actual values for the
-        styling attributes and the view configuration file allows the library to define what kind of view class is used per widget. For
-        example, it is possible to have a simple view for some widget in one theme and a more advanced version of that view in another theme.
-        The view configuration file is a pretty simple .conf file, see example below.
+    \subsection lib_themefiles Providing view configuration and style sheets for the widgets
+        External libraries can provide style sheets and view configuration for their own widgets. Style sheets contain the actual values for the
+        styling attributes, and the view configuration file allows the library to define the view class used for each widget. For
+        example, it is possible to have a simple view for a widget in one theme and a more advanced version of the view in another theme.
+        The view configuration file is a relatively simple .conf file, see the following example:
 
     \code
     [MyCustomWidget]
@@ -94,17 +95,17 @@
     }
     \endcode
 
-    \note Do not use MTheme->loadCSS() to work around this limitation, as this is slow and can lead to impossible to detect side-effects.
+    \note Do not use MTheme->loadCSS() to work around this limitation, as this is slow and can lead to side effects that are impossible to detect.
 
-    \sa \ref parent_child_in_stylesheet "Parent-child relationship in stylesheet"
-    \sa \ref theme_structure "Where to install the library specific theme files"
+    \sa \ref parent_child_in_stylesheet "Parent-child relationship in style sheet"
+    \sa \ref theme_structure "Where to install the library-specific theme files?"
 
 \section application_theme_support Theming support for applications
-    Theming support for application works in a similar way that it works for external libraries with one big exception. Libraries are only able to
-    configure the widgets they declare, but applications can override pretty much anything when it comes to theming & styling. Applications can provide
-    their own stylesheet & view configuration files, they can also register their own widgets, views & styles to the system and provide theming for them.
-    Applications have pretty much full control over their own look & feel.
-    \sa \ref theme_structure "Where to install the application specific theme files."
+    Theming support for application works in a similar way as for external libraries. The only difference is that libraries are only able to
+    configure the widgets they declare, whereas applications can override nearly anything related to theming and styling. Applications can provide
+    their own style sheet and view configuration files, and register their own widgets, views and styles to the system and provide theming for them.
+    Applications have almost full control over their own look and feel.
+    \sa \ref theme_structure "Where to install the application-specific theme files?"
 
     \note As a library or application developer, you should always provide basic theming for your widgets as a fallback theme.
 */
diff --git a/doc/src/theme_structure.dox b/doc/src/theme_structure.dox
index 62d90ac5..3538ceab 100644
--- a/doc/src/theme_structure.dox
+++ b/doc/src/theme_structure.dox
@@ -6,40 +6,40 @@
 <li><b>System theme directory/</b> <small>(/usr/share/themes)</small></li>
 <li>\c &nbsp;&nbsp;└ <b><a href="#theme">theme_x/</a></b> <small>(directory for theme-specific files)</small></li>
 <li>\c &nbsp;&nbsp;&nbsp;&nbsp;├ <a href="#theme_description">index.theme</a> <small>(theme description file)</small></li>
-<li>\c &nbsp;&nbsp;&nbsp;&nbsp;└ <b>meegotouch/</b> <small>(directory for meegotouch-specific theming files)</small></li>
-<li>\c &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;├ <a href="#theme_constants">constants.ini</a> <small>(theme specific constants)</small></li>
+<li>\c &nbsp;&nbsp;&nbsp;&nbsp;└ <b>meegotouch/</b> <small>(directory for MeeGo Touch-specific theming files)</small></li>
+<li>\c &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;├ <a href="#theme_constants">constants.ini</a> <small>(theme-specific constants)</small></li>
 <li>\c &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;├ <b><a href="#feedbacks">feedbacks/</a></b> <small>(directory for common feedbacks)</small></li>
 <li>\c &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;├ <b><a href="#theme_graphics">images/</a></b> <small>(directory for common pixmaps)</small></li>
-<li>\c &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;├ <b><a href="#theme_graphics">svg/</a></b> <small>(directory for common svg files)</small></li>
+<li>\c &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;├ <b><a href="#theme_graphics">svg/</a></b> <small>(directory for common SVG files)</small></li>
 <li>\c &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;├ <b><a href="#theme_graphics">icons/</a></b> <small>(directory for common icons)</small></li>
 <li>\c &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;├ <b><a href="#library">lib_y/</a></b><small>(directory for library-specific theme files)</small></li>
 <li>\c &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;│&nbsp;├ <a href="#library_conf">lib_y.conf</a> <small>(library-specific view configuration file)</small></li>
-<li>\c &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;│&nbsp;└ <b><a href="#library_style">style/</a></b> <small>(library-specific stylesheets)</small></li>
-<li>\c &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;│&nbsp;&nbsp;&nbsp;└ <a href="#library_css">lib_y.css</a> <small>(entry point stylesheet file for library)</small></li>
+<li>\c &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;│&nbsp;└ <b><a href="#library_style">style/</a></b> <small>(library-specific style sheets)</small></li>
+<li>\c &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;│&nbsp;&nbsp;&nbsp;└ <a href="#library_css">lib_y.css</a> <small>(entry point style sheet file for library)</small></li>
 <li>\c &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;├ <b><a href="#application">app_z/</a></b> <small>(directory for application-specific theme files)</small></li>
 <li>\c &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;│&nbsp;├ <a href="#application_conf">app_z.conf</a> <small>(application-specific view configuration file)</small></li>
 <li>\c &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;│&nbsp;├ <b><a href="#feedbacks">feedbacks/</a></b> <small>(directory for application-specific feedbacks)</small></li>
 <li>\c &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;│&nbsp;├ <b><a href="#application_graphics">images/</a></b> <small>(directory for application-specific pixmaps)</small></li>
-<li>\c &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;│&nbsp;├ <b><a href="#application_graphics">svg/</a></b> <small>(directory for application-specific svg files)</small></li>
+<li>\c &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;│&nbsp;├ <b><a href="#application_graphics">svg/</a></b> <small>(directory for application-specific SVG files)</small></li>
 <li>\c &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;│&nbsp;├ <b><a href="#application_graphics">icons/</a></b> <small>(directory for application-specific icons)</small></li>
-<li>\c &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;│&nbsp;└ <b><a href="#application_style">style/</a></b> <small>(application-specific stylesheets)</small></li>
-<li>\c &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;│&nbsp;&nbsp;&nbsp;└ <a href="#application_css">app_z.css</a> <small>(entry point stylesheet for application)</small></li>
+<li>\c &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;│&nbsp;└ <b><a href="#application_style">style/</a></b> <small>(application-specific style sheets)</small></li>
+<li>\c &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;│&nbsp;&nbsp;&nbsp;└ <a href="#application_css">app_z.css</a> <small>(entry point style sheet for application)</small></li>
 <li>\c &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;└ <b><a href="#locale">locale/</a></b><small>(directory for different locales)</small></li>
 <li>\c &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;└ <b><a href="#locale_l">en/</a></b> <small>(directory for locale-specific theme files)</small></li>
-<li>\c &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;├ <a href="#locale_constants">constants.ini</a> <small>(locale specific constants)</small></li>
-<li>\c &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;└ <b><a href="#locale_icons">icons/</a></b> <small>(locale specific icons)</small></li>
+<li>\c &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;├ <a href="#locale_constants">constants.ini</a> <small>(locale-specific constants)</small></li>
+<li>\c &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;└ <b><a href="#locale_icons">icons/</a></b> <small>(locale-specific icons)</small></li>
 </ul>
 
-\subsection theme Theme Directory
+\subsection theme Theme directory
 
 The system can have multiple themes and they are all located in /usr/share/themes/.
-Each theme has one root direcory, which will contain all necessary files for the theme.
+Each theme has one root directory, which contains all necessary files for the theme.
 So if you are developing a theme, you should start by creating a new directory under /usr/share/themes.
 
-\subsection theme_description Theme Description File (index.theme)
+\subsection theme_description Theme description file (index.theme)
 
-The description file is something every theme has to have. The file contains information about the theme: name, version, etc.
-For example the index.theme file could look like this:
+Every theme should have a description file. The file contains the name, version, and other information about the theme.
+The following example illustrates an index.theme file:
 \code
 [Desktop Entry]
 Type=X-MeeGoTouch-Metatheme
@@ -51,19 +51,25 @@ X-Inherits=base
 X-Icon = icon-theme-logo
 X-Visible=true
 \endcode
-Where value for X-Inherits must be an existing theme (e.g. base in common case).
+Where value for X-Inherits must be an existing theme (for example, base in common case).
 TODO: explain all key-value pairs
 
-\subsection theme_constants Theme Constants File (constants.ini)
+\subsection theme_constants Theme constants file (constants.ini)
 
 This file contains constant definitions for this theme. The constant set is predefined and can be found from /usr/share/themes/base/constants.ini.
-Constants are used in application code (MPalette, MDefaultFonts), and in stylesheets.
+Constants are used in application code (MPalette, MDefaultFonts), and in style sheets.
 
-When creating a new theme, this file is the one to start with. Just create an empty constants.ini and add a few lines from base:constants.ini
-with modified values. Now your theme contains \ref theme_description "index.theme", and constants.ini; and is already a functional theme to be tried out!
-This is enough because MeeGo Touch themes can inherit other themes. There is no need to copy some existing theme and
-start modifying it, instead it's recommended to inherit some theme and just change the parts you want.
-Here's a peek into one of the stylesheets from the base-theme.
+When creating a new theme, start with the constants file. 
+
+To create the file:
+
+1. Create an empty constants.ini.
+2. Add a few lines from base:constants.ini with modified values. 
+
+Now your theme contains \ref theme_description "index.theme", and constants.ini, and it is ready for testing.
+No other steps are necessary, since MeeGo Touch themes can inherit other themes. Instead of copying 
+and modifying an existing theme, it is recommended to inherit a theme and change the parts you want.
+The following example illustrates one of the style sheets from the base theme:
 \code
 MButtonStyle {
     font: $FONT_DEFAULT;
@@ -72,10 +78,11 @@ MButtonStyle {
     background-color: $COLOR_BACKGROUND;
     text-color: $COLOR_FOREGROUND;
 \endcode
-And as we see the base theme contains style definitions that are made by using constants. So when declaring your own values for the constants,
-you are changing the style attribute values which are defined by using constants like $COLOR_BACKGROUND.
+The base theme contains style definitions that are made with constants. When you declare your 
+own values for the constants, you change the style attribute values defined with constants such as 
+$COLOR_BACKGROUND.
 
-Below is an example of constants.ini which changes the default colors for this theme.
+The following example illustrates constants.ini that changes the default colours for the theme:
 \code
 [Palette]
 COLOR_FOREGROUND            = #fafafa ;text color
@@ -87,17 +94,17 @@ COLOR_INVERTED_FOREGROUND           = #090909 ;text color
 COLOR_INVERTED_SECONDARY_FOREGROUND = #595959 ;secondary text
 COLOR_INVERTED_BACKGROUND           = #00ffff ;background
 \endcode
-The rest of the values for constants.ini will come from the theme from which you inherited your own.
 
-\subsection theme_graphics Theme Graphics Directories
+The rest of the values for constants.ini comes from the theme from which you inherited your own theme.
 
-There are three directories under each theme; images, svg and icons. These directories contains all common graphics for the theme.
-So if you're not pleased with your theme by just changing \ref theme_constants "constants.ini" you can always start replacing
+\subsection theme_graphics Theme graphics directories
+
+There are three directories under each theme; images, svg and icons. The directories contain all the common graphics for the theme.
+Thus, if you are not pleased with your theme after just changing \ref theme_constants "constants.ini" you can always replace
 graphics.
 
-ImageId is a unique name for a piece of graphic. This imageId can be used from application code and from stylesheets and is also a reason, why
-just by adding graphics to any of these three directories, you can modify your theme.
-Here's the same peek into one of the stylesheets from the base-theme
+ImageId is a unique name for a graphic object. This imageId can be used from application code and from style sheets. The imageID enables you to modify your theme by adding graphics to any of the three directories.
+The following example illustrates one of the style sheets from the base theme:
 \code
 MButtonStyle {
     font: $FONT_DEFAULT;
@@ -106,105 +113,101 @@ MButtonStyle {
     background-color: $COLOR_BACKGROUND;
     text-color: $COLOR_FOREGROUND;
 \endcode
-We can see that the "background-image" attribute for the button has a value "meegotouch-button-background". This "meegotouch-button-background" is the imageId.
-To override the background-image graphics in MButton, you just need to place the replacement for example into the svg/ directory. The funky part is the imageId.
-Here's how the imageIds for the three directories are defined:
+The "background-image" attribute for the button has a value "meegotouch-button-background". This "meegotouch-button-background" is the imageId.
+To override the background-image graphics in MButton, you just need to place the replacement, for example, in the svg/ directory. The funky part is the imageId.
+The imageIds for the three directories are defined as follows:
 
-\li The images/ directory can contain only pixmaps (for example .png and .jpg), so it's a place for wallpapers etc. In this folder the filename of the
-image (without the suffix) is the imageId.
+\li The images/ directory can contain only pixmaps (for example PNG and JPG files, and is suitable, for instance, for wallpapers. In this directory, the imageID is the file name of the image (without the suffix).
 
-\li The svg/ directory is a place for scalable vector graphics, and is mainly targeted for component(widget) graphics. The recommended way is to create
-one .svg file per component. The element names in the svg-files are used as imageIds in this directory.
+\li The svg/ directory can contain scalable vector graphics, and is mainly targeted for component (widget) graphics. It is recommended that you create
+one SVG file for each component. In this directory, the imageId is the element name in the SVG file.
 
-\li The icons/ directory can contain only .svg files and difference to svg/ is that files in this directory are treated so that each file represents one imageId.
-filename of the .svg (without the suffix) is the imageId in this directory.
+\li The icons/ directory can contain only SVG files. As opposed to svg/ directory, each file in this directory represents one imageId. In this directory, the imageId is the file name of the .svg (without the suffix).
 
-So to create a replacement for the meegotouch-button-background image, just create an SVG called meegotouch-button.svg (for example) and place it under svg/.
+To create a replacement for the meegotouch-button-background image, create an SVG called meegotouch-button.svg (for example) and place it under svg/.
 Then add an element called meegotouch-button-background and create your graphics there.
 
-\subsection library Library Directory
+\subsection library Library directory
 
-Every library which provides some new components(widgets) has to also provide default styling attributes for those. Developers of the library will place the default
-attribute values into \ref library_style "/usr/share/themes/base/meegotouch/&lt;libraryname&gt;/style/". Also, if the library providing these components has made it
-possible to change the view part of the component, the developer of the library has placed the initial view configuration into
+Every library that provides new components(widgets) also has to provide default styling attributes for them. Developers of the library place the default
+attribute values into \ref library_style "/usr/share/themes/base/meegotouch/&lt;libraryname&gt;/style/". Additionally, if the library providing these components has made it possible to change the view part of the component, the developer of the library has placed the initial view configuration into
 \ref library_conf "/usr/share/themes/base/meegotouch/&lt;libraryname&gt;/&lt;libraryname&gt;.conf".
 
-There is one directory for each library to be themed. Normally it's not necessary to create these library theming folders for your theme. In case you need to
-change attibutes in stylesheets or you need to change the view part of a component anyway, you must create a directory which has the same name as the library providing the
-component (for example libnicewidgets-extras/).
+There is one directory for each library to be themed. Normally it is not necessary to create these library theming folders for your theme. In case you need to
+change attributes in style sheets or you need to change the view part of a component anyway, you must create a directory which has the same name as the library providing the component (for example libnicewidgets-extras/).
+
+\subsection library_style Library style sheet directory
 
-\subsection library_style Library Stylesheet Directory
+This directory can contain any number of style sheet files. It is recommended that every component(widget) in the library which can be styled should have its own CSS file. This directory must contain one CSS file which is the \ref library_css "entry point". For more information on style sheets, see \ref styling_stylesheets "Styling with style sheets".
 
-This directory can contain any number of stylesheet files. The recomendation is that every component(widget) in the library which can be styled would have it's own css-file.
-This directory must contain one css file which is the \ref library_css "entry point". More about stylesheets can be found under \ref styling_stylesheets "Stylesheets".
+\subsection library_css Library main style sheet file
 
-\subsection library_css Library Main Stylesheet File
+This file is located in the \ref library_style "style" directory, and its name must follow the name of the library (for example, libnicewidgets-extras.css).
+The system reads this file when reading style attributes for a class coming from this library. All other files in \ref library_style "style"
+should be \ref import_sheet "@imported" from this file to ensure that they are also read.
 
-This file is located in the \ref library_style "style" directory, and its name must follow the name of the library (for example libnicewidgets-extras.css).
-This file will be the one which the system will read when reading style attributes for a class coming from this library. All other files in \ref library_style "style"
-should be \ref import_sheet "@imported" from this file so they will also get read.
+\subsection library_conf Library view configuration file
 
-\subsection library_conf Library View Configuration File
+This file contains a component(widget) - view pairs. Normally you do not need to have this file in your theme, since the default values come from the theme you are inheriting from.
+However, you can use this file if, for example, you want to create a button with a better look and you cannot do this by changing only the CSS file and graphics.
 
-This file contains a component(widget) - view pairs. Normally you don't need to have this file in your theme, the default values are coming from the theme you're inheriting from.
-If, for example, you want to create a button with a better look than is possible by changing just css and graphics, than this is the place to do that.
 TODO: view libraries + link to view-config explanation
 
-\subsection application Application Directory
+\subsection application Application directory
 
-All applications can provide additional styling for themselves, the application directory must have the same name as the application to be styled (for example widgetsgallery/).
+All applications can provide additional styling for themselves, and the application directory must have the same name as the application to be styled (for example, widgetsgallery/).
 
-This directory can contain \ref application_graphics "graphics", \ref application_style "stylesheets" and \ref application_conf "view configuration" for the application.
+This directory can contain \ref application_graphics "graphics", \ref application_style "style sheets" and \ref application_conf "view configuration" for the application.
 
-\subsection application_graphcis Application Graphics Directories
+\subsection application_graphcis Application graphics directories
 
-Usually when creating a theme you don't have to override the base-theme definitions for applications (most of the applications probably don't even have any special styling).
-If anyways you want some specific application to look different than the theme specifies, you can do it by creating application-specific styling.
-Applications can override theme default graphics by inserting files into the images/, svg/ or icons/ directories. The graphics overriding works the same way as it works with theme inheritance, so see \ref theme_graphics "Theme Graphics" for more info.
+When creating a theme, you do not usually have to override the base theme definitions for applications. Most of the applications probably do not even have any special styling.
+However, if you want a specific application to look different than specified in the theme, you can create application-specific styling.
+Applications can override theme default graphics by inserting files into the images/, svg/ or icons/ directories. Graphics are overridden in the same way as themes are inherited. For more information, see \ref theme_graphics "Theme graphics".
 
-\subsection application_style Application Stylesheet Directory
+\subsection application_style Application style sheet directory
 
-Applications can override the themes default stylesheet attribute values by creating an application stylesheet \ref application_css "entry point".
-Applications can override any attributes from any component. Everything that is not overridden will still come from the theme, so the recommendation is that applications override as few attributes as possible.
+To override the default style sheet attribute values of a theme in an application, you can create an application style sheet \ref application_css "entry point".
+Applications can override any attributes from any component. Anything that is not overridden still comes from the theme, so it is recommended that applications override as few attributes as possible.
 
-\subsection application_css Application Main Stylesheet File
+\subsection application_css Application main style sheet file
 
 This file is located in the \ref application_style "style" directory, and the name of the file has to be equal to the application name.
 
-\subsection application_conf Application View Configuration File
+\subsection application_conf Application view configuration file
 
 TODO: explain more.
 
 \subsection feedbacks Feedbacks
 
-The feedbacks are stored in the subdirectory "feedbacks" next to "style", "svg" etc. on the same directory level in the themes. A directory is associated to each feedback under the subdirectory "feedbacks" whose name is the feedback name. For example, feedback sample files for a common feedback named "press" of the theme "base" should be located in the "/usr/share/themes/base/meegotouch/feedback/press" directory. The directory names are case sensitive and follow the icon name conventions of the FreeDesktop project (http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html). Therefore "all names may only contain lowercase letters, numbers, underscore, dash, or period characters. Spaces, colons, slashes, and backslashes are not allowed". If a directory name does not follow these rules then it is ignored. These subdirectories contain the feedback sample files which can be played by the backends.
+The feedbacks are stored in the subdirectory "feedbacks" (next to "style", "svg" , and so on) at the same directory level in the themes. For each feedback, the feedbacks directory has a subdirectory corresponding to the feedback name. For example, feedback sample files for a common feedback named "press" of the theme "base" should be located in the "/usr/share/themes/base/meegotouch/feedback/press" directory. The directory names are case-sensitive and follow the icon name conventions of the FreeDesktop project (http://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html). Therefore, "all names may only contain lower-case letters, numbers, underscore, dash, or period characters. Spaces, colons, slashes, and backslashes are not allowed". If a directory name does not follow these rules, it is ignored. These subdirectories contain the feedback sample files which can be played by the backends.
 
-The common feedback directory of the "base" theme contains all the common feedbacks for MeeGo Touch common components and external libraries. The "base" theme contains all of the common feedbacks. This means that new themes that derive from the "base" theme can only override existing feedbacks that are already present in the "base" theme. Any new feedbacks that the derived themes introduce will be ignored.
+The common feedback directory of the base theme contains all the common feedbacks for MeeGo Touch common components and external libraries. The base theme contains all of the common feedbacks. This means that new themes that derive from the base theme can only override existing feedbacks that are already present in the base theme. Any new feedbacks that the derived themes introduce are ignored.
 
-Application specific feedbacks are placed in the application specific feedback directory in the theme directory structure. Applications can override any existing common feedback in the base theme and can add new feedbacks as well. Any new feedbacks should be placed in the application specific feedback directory of the "base" theme. These feedbacks can be overridden by derived themes but here also derived themes cannot introduce any new feedbacks that are not present in the "base" theme.
+Application-specific feedbacks are placed in the application-specific feedback directory in the theme directory structure. Applications can override any existing common feedback in the base theme and add new feedbacks as well. Any new feedbacks should be placed in the application-specific feedback directory of the base theme. The feedbacks can be overridden by derived themes. However, derived themes cannot introduce any new feedbacks that are not present in the base theme.
 
-Pulseaudio backend: This backend plays audio samples from the device speakers. It is recommended to provide feedback files for this backend in the native format of the audio sink. Files that are not in the native format will be converted to native fromat each time the feedback gets loaded. This assures lowest possible latency when playing the audio effects. The pulseaudio backend supports only wav files and the name of the audio file must be "audio.wav".
+Pulseaudio backend: This backend plays audio samples from the device speakers. It is recommended to provide feedback files for this backend in the native format of the audio sink. Files that are not in the native format are converted to native format each time the feedback is loaded. This assures the lowest possible latency when playing the audio effects. The pulseaudio backend supports only WAV files and the name of the audio file must be "audio.wav".
 
 Vibra backend: This backend uses the Immersion TouchSense player to play vibra effects. A vibration effect file ("vibra.ivt") must be placed in the feedback directory.
 
-When an event happens (e.g. pressing on a button), then all feedback devices will play a sample at the same time (play an audio and vibra effect in parallel). If a feedback directory does not contain an effect file for a backend (e.g. "vibra.ivt") then there is a fallback mechanism to find a sample for the backend going back on the theme inheritance tree. One example of theme inheritance for a feedback could be: "base/feedbacks", "inherited1/feedbacks", "inherited2/feedbacks", "base/application/feedbacks", "inherited1/application/feedbacks", "inherited2/application/feedbacks". Here "base/feedbacks" means common feedback directory of the "base" theme etc. The last directory in the list is the first place to look for the feedback. If a zero sized sample file (either "audio.wav" or "vibra.ivt") is placed somewhere in the inheritance tree, that means that the feedback is not played for the backend that the sample file belongs to. If it is not possible to load some samples for a specific event (e.g. "press-loud") then it tries to fallback to a generic event name (e.g. "press-loud" -> "press") and load the missing sample(s). Please note that the fallback mechanism only works for the text before the first dash ('-'). For example fallback for feedbacks "press-really-loud" and "press-loud" is "press".
+When an event, such as pressing a button, takes place, all feedback devices play a sample at the same time (play an audio and vibra effect in parallel). If a feedback directory does not contain an effect file for a backend (such as "vibra.ivt"), there is a fallback mechanism to find a sample for the backend going back on the theme inheritance tree. One example of theme inheritance for a feedback could be: "base/feedbacks", "inherited1/feedbacks", "inherited2/feedbacks", "base/application/feedbacks", "inherited1/application/feedbacks", "inherited2/application/feedbacks". Here "base/feedbacks" means common feedback directory of the "base" theme, and so on. The last directory in the list is the first place to look for the feedback. If a zero-sized sample file (either "audio.wav" or "vibra.ivt") is placed somewhere in the inheritance tree, that means that the feedback is not played for the backend that the sample file belongs to. If it is not possible to load some samples for a specific event (for example, "press-loud") then it tries to fallback to a generic event name (for example, "press-loud" -> "press") and load the missing sample(s). Note that the fallback mechanism only works for the text before the first dash ('-'). For example, fallback for feedbacks "press-really-loud" and "press-loud" is "press".
 
-The feedbacks can be played on three different global volume levels. This is a global setting of the feedback daemon, but the feedbacks should be prepared for it. The Pulseaudio backend sets the appropriate playback volume for the audio, nothing should be done here. The vibra backend checks the "vibra.ivt" file for three specific timeline effects named "low", "medium" and "high" which refers to low, medium and high levels. If these timeline effects are not available in the effect file then the fallback logic uses the first effect from the file (its type does not matter in this case).
+The feedbacks can be played on three different global volume levels. This is a global setting of the feedback daemon, but the feedbacks should be prepared for it. The Pulseaudio backend sets the appropriate playback volume for the audio, nothing should be done here. The vibra backend checks the "vibra.ivt" file for three specific timeline effects, named "low", "medium" and "high", which refer to low, medium and high levels. If these timeline effects are not available in the effect file, the fallback logic uses the first effect from the file (in this case, its type does not matter).
 
-\subsection locale Locales Directory
+\subsection locale Locales directory
 
-This directory contains directories for different locales. All locales needing some special icons or constant definitions can have their own directory. For example ar/ (for Arabic) could have a different icon set than the normal theme (as Arabic has right-to-left layouts). Another example could be zh_CN/ (for Simplified Chinese) having bigger fonts.
+This directory contains directories for different locales. All locales that need some special icons or constant definitions can have their own directory. For example, ar/ (for Arabic) may have a different icon set than the normal theme (as Arabic has right-to-left layouts). Another example could be zh_CN/ (for Simplified Chinese) that has bigger fonts.
 
-\subsection locale_l Locale Specific Directory
+\subsection locale_l Locale-specific directory
 
-This directory is located at /usr/share/themes/\<theme\>/meegotouch/locale/\<locale\>/ where the \<locale\> is fi, en, etc. Definitions in this directory will be applied for \<theme\> when the \<locale\> matches the system locale.
+This directory is located at /usr/share/themes/\<theme\>/meegotouch/locale/\<locale\>/ where the \<locale\> is fi, en, and so on. Definitions in this directory are applied for \<theme\> when the \<locale\> matches the system locale.
 
-\subsection locale_constants Locale Specific Constants
+\subsection locale_constants Locale-specific constants
 
-This file can contain fonts and color definitions for the locale.
+This file contains fonts and colour definitions for the locale.
 
-\subsection locale_icons Locale Specific Icons Directory
+\subsection locale_icons Locale-specific icons directory
 
-This directory can contain any number of icons which will override the themes icons when the locale matches the system locale setting. The icons in this folder must exist in the \ref theme_graphics "theme icons" directory.
+This directory contains any number of icons which override the theme icons when the locale matches the system locale setting. The icons in this folder must exist in the \ref theme_graphics "theme icons" directory.
 
 */
diff --git a/doc/src/tutorial.dox b/doc/src/tutorial.dox
index 2684f990..7b05ad32 100644
--- a/doc/src/tutorial.dox
+++ b/doc/src/tutorial.dox
@@ -1,151 +1,157 @@
-/*! \page tutorial Your first MeeGo Touch application
+/*! \page tutorial Creating your first MeeGo Touch application
 
 This document explains, step-by-step, how to create a simple MeeGo Touch application.
-Knowledge of the basics of Qt framework, such as QObject and its signals and slots mechanism, is recommended.
-On the other hand, even though MeeGo Touch framework is built on top of Qt's Graphics Framework (QGraphicsView, QGraphicsScene, QGraphicsItem, etc) no prior knowledge of it is needed.
+It is recommended that you have a basic knowledge of Qt framework, such as QObject and its signals and slots mechanism.
+On the other hand, even though MeeGo Touch framework is built on top of Qt's Graphics Framework (QGraphicsView, QGraphicsScene, QGraphicsItem, and so on) no prior knowledge of it is needed.
 
 The complete source code of the finished "Music Catalogue" example application can be found in the following location:
 \verbatim
 libmeegotouch/examples/tutorial_music_catalogue
 \endverbatim
 
-\section mapplication Application class
+\section mapplication Adding an application class
 
-Let's start by creating a new directory for our tutorial application and creating its <code>main.cpp</code> file. 
+Start by creating a new directory for the tutorial application and its <code>main.cpp</code> file. 
 
-The first object to be added is MApplication. It handles the main event loop and initializes some internal structures needed by the framework. <code>main.cpp</code> should therefore look like the following:
+The first object that you need to add is MApplication. It handles the main event loop and initialises some internal structures needed by the framework. Therefore, <code>main.cpp</code> should be:
 
 \include tutorial_main_step_01.cpp
 
-In the next step we will already build and run it to see what happens.
+The following section describes how to build and run the application.
 
-\section qmake Creating project file and building for the first time
+\section qmake Creating a project file and building the application
 
-As MeeGo Touch UI framework is built on top of Qt we also use Qt's building system, <code>qmake</code>.
+As MeeGo Touch UI framework is built on top of Qt, Qt's building system, <code>qmake</code>, is used.
 
-First we tell qmake to generate a project file for us. Issue the follwing command from within the tutorial application directory.
+1. To generate a project file with qmake, issue the following command from within the tutorial application directory.
 
 \code
 $ qmake -project
 \endcode
 
-That will generate a project file (ends with <code>.pro</code>) in the current directory. Its contents should look like the following:
+This generates a project file (ending with <code>.pro</code>) in the current directory. Its contents should be:
 
 \include tutorial.pro
 
-That project file is suitable for building plain Qt applications but won't work as it is for MeeGo Touch ones. To bring in the MeeGo Touch libraries, headers and compilation options into the build all that is needed is the addition of the following line to the project file: 
+The project file is suitable for building plain Qt applications, but it does not work for MeeGo Touch applications yet. 
+
+2. To include the MeeGo Touch libraries, headers and compilation options in the build, add the following line to the project file: 
 
 \code
 CONFIG += meegotouch
 \endcode
 
-Now that we have our project file properly set, let's generate the actual build scripts (Makefile) from it.
+You have now created a proper project file for MeeGo Touch. 
+
+3. Generate the actual build scripts (Makefile) from the project file:
 
 \code
 $ qmake
 \endcode
 
-And then finally build it.
+4. Build the application:
 
 \code
 $ make
 \endcode
 
-For more information on qmake, check qmake's documentation.
+For more information on qmake, see the qmake documentation.
 
-\section mapplicationwindow Application window
+\section mapplicationwindow Creating an application window
 
-If you run your application now, nothing will appear on the screen. Thus the next step is to add code to create our main application window so that we can get something displayed.
+If you run your application now, nothing appears on the screen. The next step is to add the required code to create the main application window so that something is displayed.
 
-In MeeGo Touch, the main window is provided by the <code>MApplicationWindow</code> class. So let's add one and show it. The code of our minimal application should now look like this:
+In MeeGo Touch, the main window is provided by the <code>MApplicationWindow</code> class. Add the class and display it. The code of the minimal example application should now be:
 
 \include tutorial_main_step_02.cpp
 
-If you build and run it now, a new window should appear containing on its top edge some bars and navigation controls. Otherwise the window is pretty much empty. That empty space is to be occupied by the application's actual content. In MeeGo Touch, application content is organized into pages, which is the topic of our next section.
+If you build and run it now, the applications should display a new window which contains bars and navigation controls at the top. Otherwise the window is relatively empty. The actual content of the application appears in the empty space. In MeeGo Touch, application content is organised into pages. For more information, see the following section.
 
-\section mapplicationpage Application page
+\section mapplicationpage Creating an application page
 
-An application page takes the entire screen and is covered by the bars and controls you've seen in the last section. It provides an unlimited area where a central widget is spread out. The page content goes inside this central widget. If the central widget happens to be bigger than the screen, all its content can still be accessed by panning the page.
+An application page covers the entire screen and includes the bars and controls as described in the previous section. It provides an unlimited area where a central widget is spread out. The page content is located inside the central widget. If the central widget is bigger than the screen, its entire content can still be accessed by panning the page.
 
-The application page class is called <code>MApplicationPage</code>. Let's create one and assign a label (<code>MLabel</code> class) with the text "Hello World!" as its central widget so that we get to see some content. As with all scene windows (more on that soon), to get it displayed on our window we have to make it appear by calling its <code>appear()</code> method. Also it would be a good idea to give our page a title. You can do so by calling its <code>setTitle()</code> method.
+The application page class is called <code>MApplicationPage</code>. Create an application page and assign a label (<code>MLabel</code> class) with the text "Hello World!" as its central widget to display some content on the page. As with all scene windows, you need to call its <code>appear()</code> method to display it on the window. To give the page a title, call its <code>setTitle()</code> method.
 
-With the addition of the application page our <code>main.cpp</code> should now look like the following:
+The <code>main.cpp</code> should now be:
 \include tutorial_main_step_03.cpp
 
-Now you should be able to see the title of your page being displayed in the navigation bar and the "Hello World!" text below it. You can also try to pan the page to see what happens. Since the text fits within the screen boundaries the page bounces back to its original position after each panning gesture.
+Now the title of your page should be displayed in the navigation bar and the "Hello World!" text below it. You can also try to pan the page to see what happens. Since the text fits within the screen boundaries, the page bounces back to its original position after each panning gesture.
 
 \image html "hello_world_ready.jpg" "\"Hello World!\" application"
 
 This is the minimal code to get a "Hello World!" MeeGo Touch application working.
 
 \subsection mapplicationpage_furtherreading Further reading
-Understand the \subpage sceneandscenewindows "MeeGo Touch scene and its scene windows".
+For more information, see \subpage sceneandscenewindows "Scene and scene windows".
 
 \section tutorial_pagenavigation Navigating between pages
 
-A MeeGo Touch application can have several pages. An action done in a page may programatically trigger the appearance of a new one, which will cause the current one to disappear as only one page can be displayed at any given time.
+A MeeGo Touch application can have several pages. If an action is performed on one page, it may trigger the appearance of a new page. Since only one page can be displayed at any given time, this causes the current page to disappear.
 
-Navigation between pages is most commonly done from a main page to child/sub pages, in a hierarchical fashion. This navigational pattern is known as "Drill Down".
+When navigating between pages, you normally switch from a main page to child/sub pages, in a hierarchical fashion. This is known as the drill-down navigation pattern.
 
-To showcase this navigational pattern we will modify our "Hello World!" application to emulate a simple Music Catalogue app.
+To illustrate this navigation pattern, this example shows how to modify the "Hello World!" application to emulate a simple Music Catalogue application.
 
-\image html "music_catalogue_navigation.jpg" "Navigational pattern of our \"Music Catalogue\" application"
+\image html "music_catalogue_navigation.jpg" "Navigation pattern of a \"Music Catalogue\" application"
 
-From the figure above you can see that we have three different pages (from left to right): Main page, artist page and album page.
+The previous figure illustrates that there are three different pages (from left to right): Main page, artist page, and album page.
 
-Our application start by showing an application window with our main page appearing in it. That's how our <code>main.cpp</code> will look like:
+The application starts by showing an application window which displays the main page. The <code>main.cpp</code> is:
 
 \include tutorial_music_main.cpp
 
-We don't have to worry about deleting <code>mainPage</code> later since the <code>appear()</code> call transfers the ownership of the page to the underlying scene.
+It is not necessary to delete the <code>mainPage</code> later, since the <code>appear()</code> call transfers the ownership of the page to the underlying scene.
 
-For an implementation of <code>fillOutData()</code> that adds some hardcoded content check \subpage tutorialMusicFillOutData "here".
+For information on the <code>fillOutData()</code> that adds hardcoded content, see \subpage tutorialMusicFillOutData "here".
 
-Our data classes in <code>data.h</code>:
+The data classes in <code>data.h</code> are:
 
 \include tutorial_music_data.h
 
 \subsection musicMainPage MainPage
 
-Our <code>MainPage</code> is a specialization of <code>MApplicationPage</code>. It takes as a parameter in its constructor the list of artists and it displays then as a list of buttons. When an artist's button gets clicked, a new page showing his information appears.
+The <code>MainPage</code> is a specialised version of <code>MApplicationPage</code>. It takes as a parameter in its constructor the list of artists and displays them as a list of buttons. When you tap an artist's button, a new page appears with their information.
 
-\image html "music_mainpage.jpg" "Main page of our \"Music Catalogue\" application"
+\image html "music_mainpage.jpg" "Main page of the \"Music Catalogue\" application"
 
 \include tutorial_music_mainpage.cpp
 \include tutorial_music_mainpage.h
 
 \subsection musicArtistPage ArtistPage
 
-The <code>ArtistPage</code> is very similar to MainPage. It takes an <code>Artist</code> object and displays his albums as buttons. When an album's button gets clicked a new page showing the album appears.
+The <code>ArtistPage</code> is very similar to MainPage. It takes an <code>Artist</code> object and displays the artist's albums as buttons. When you tap an album's button, a new page showing the album appears.
 
 \include tutorial_music_artistpage.cpp
 \include tutorial_music_artistpage.h
 
 \subsection musicAlbumPage AlbumPage
 
-<code>AlbumPage</code> is our last and innermost page, navigation-wise. It takes an <code>Album</code> object and displays its cover art, artist and song list.
+<code>AlbumPage</code> is the last and innermost page, from the navigation point of view. It takes an <code>Album</code> object and displays its cover art, artist and song list.
 
-\image html "music_albumpage.jpg" "Album page of our \"Music Catalogue\" application"
+\image html "music_albumpage.jpg" "Album page of the \"Music Catalogue\" application"
 
 \include tutorial_music_albumpage.cpp
 \include tutorial_music_albumpage.h
 
 \subsection musicCompiling Compiling
 
-Update your project file with all those new sources and headers:
+To compile the Music Catalogue application:
+
+1. Update your project file with all the new sources and headers:
 
 \code
 HEADERS += albumpage.h data.h mainpage.h artistpage.h
 SOURCES += main.cpp mainpage.cpp artistpage.cpp albumpage.cpp
 \endcode
 
-Regenerate the build script
+2. Regenerate the build script:
 
 \code
 $ qmake
 \endcode
 
-And build it again.
+3. Build the application again:
 
 \code
 $ make
@@ -153,37 +159,37 @@ $ make
 
 \subsection pagenavigation_furtherreading Further reading
 
-For our lists we used MButtons in a vertical QGraphicsLayout. This approach is straightforward but if our lists had hundreds or even thousands of items we would suffer significant perfomance issues, to say the least. For those cases MList should be used. Its usage is not as simple as what we did but it gracefully handles lists of any size. Read MList documentation and refactor the "Music Catalogue" example to use MList.
+For the lists of the example application, MButtons in a vertical QGraphicsLayout were used. This approach is straightforward but if there are lists with hundreds or even thousands of items, it causes performance issues, to say the least. For those cases, use MList. Its usage is not as simple as in the example, but it gracefully handles lists of any size. To try out MList, read the MList documentation and refactor the "Music Catalogue" example to use MList.
 
-Read about Drill Down and other navigational patterns in: \subpage pagenavigation
+For more information on drill-down and other navigation patterns, see \subpage pagenavigation.
 
-\section screenOrientation Dealing with different screen orientations (portrait vs. landscape)
+\section screenOrientation Handling portrait and landscape orientations
 
-In MeeGo Touch, the GUI can be rotated to four different angles in the screen (0, 90, 180 and 270 degrees clockwise). Angles 0 and 180 are landscape (width larger than height), 90 and 270 are portrait (height larger than width).
+In MeeGo Touch, the GUI can be rotated to four different angles on the screen (0, 90, 180 and 270 degrees clockwise). Angles 0 and 180 are in landscape mode (the width is greater than the height), 90 and 270 are in portrait mode (the height is greater than the width).
 
-When changing from a landscape to a portrait orientation angle and vice-versa the available space for the GUI can change significantly (e.g., from being a broad page to be a very narrow one). Because of that, a page might need different layouts for portrait and landscape so that it looks nice and is usable in any orientation. To easily achieve that, MeeGo Touch provides the class MLayout.
+When changing from a landscape to a portrait orientation angle and the opposite, the available space for the GUI can change significantly (for example, a broad page can change into a very narrow one). Thus, a page may need different layouts for portrait and landscape, so that it looks nice and is usable in any orientation. To easily achieve that, MeeGo Touch provides the class MLayout.
 
-Unlike a regular QGraphicsLayout where you add items directly to it, in MLayout items are added to layout policies and then those policies are set to specific orientations of a MLayout (i.e. the landscape layout policy and the portrait layout policy of an MLayout).
+Unlike a regular QGraphicsLayout where you add items directly to it, in MLayout items are added to layout policies and the policies are set to specific orientations of an MLayout (which refer to the landscape layout policy and the portrait layout policy of an MLayout).
 
-Now let's modify the AlbumPage of our Music Catalogue application to make it use a vertical layout when in portrait and a horizontal one when in landscape, like shown in the figure below:
+The following example illustrates how to modify the AlbumPage of a Music Catalogue application to use a vertical layout when it is in a portrait orientation angle and horizontal layout when it is in a landscape orientation angle. See the following figure:
 
 \image html "music_albumpage_layout_orientations.jpg" "Different layouts for the AlbumPage according to the screen orientation"
 
-To achieve this we only have to modify the implementation of AlbumPage::createContent(). Instead of having all elements (cover art, artist name and song list) in a single layout we will have two separate sub-layouts: one holding the cover art and artist name, the other holding the song list. When in landscape orientation the two sub-layouts will be arranged side-by-side and in portrait orientation they will be on top of each other.
+To achieve this, modify the implementation of AlbumPage::createContent(). Instead of having all elements (cover art, artist name and song list) in a single layout, there are two separate sub-layouts. One layout holds the cover art and the artist name, and the other one holds the song list. In a landscape orientation the two sub-layouts are arranged side by side, whereas in portrait orientation they are on top of each other.
 
 \include tutorial_orientations_albumpage.cpp
 
 \subsection screenOrientation_furtherreading Further reading
 
-MeeGo Touch also provides methods to query and set the GUI orientation as well as signals that get emitted whenever the orientation changes. Read \subpage rotation for more information.
+MeeGo Touch also provides methods to query and set the GUI orientation as well as signals that are emitted whenever the orientation changes. For more information, see \subpage rotation.
 
-\section animations Animations
+\section animations Creating animations
 
-Properties of graphical items can be easily animated using QPropertyAnimation class. To exemplify this let's animate the cover art image of our album page by making it fade in after the AlbumPage gets displayed.
+Properties of graphical items can be easily animated using QPropertyAnimation class. This section explains how to animate the cover art image of an album page by making it fade in after the AlbumPage is displayed.
 
-When a page finishes appearing it emits the signal <code>appeared()</code>. What we will do is create a slot called <code>fadeInAlbumCover()</code> that we will connect to the <code>appeared()</code> signal of our <code>AlbumPage</code> class.
+When a page is completely displayed, it emits the signal <code>appeared()</code>. The following example shows how to create a slot called <code>fadeInAlbumCover()</code> and connect it to the <code>appeared()</code> signal of the <code>AlbumPage</code> class.
 
-That's the implementation of our <code>fadeInAlbumCover()</code> slot:
+The <code>fadeInAlbumCover()</code> slot is implemented as follows:
 \code
 #include <QPropertyAnimation>
 
@@ -200,9 +206,9 @@ void AlbumPage::fadeInAlbumCover()
     fadeInAnimation->start(QAbstractAnimation::DeleteWhenStopped);
 }
 \endcode
-It will animate the opacity property of <code>albumCover</code> from 0.0 (fully transparent) to 1.0 (fully opaque) in one second (1000 milliseconds).
+This animates the opacity property of <code>albumCover</code> from 0.0 (fully transparent) to 1.0 (fully opaque) in one second (1000 milliseconds).
 
-<code>fadeInAlbumCover()</code> slot is declared in <code>albumpage.h</code> in the following way:
+<code>fadeInAlbumCover()</code> slot is declared in <code>albumpage.h</code> as follows:
 \code
 class AlbumPage : public MApplicationPage {
    ...
@@ -212,9 +218,9 @@ private slots:
 };
 \endcode
 
-Note that <code>albumCover</code> has to be made a class variable of AlbumPage instead of an internal variable of <code>AlbumPage::createContent()</code> so that <code>AlbumPage::fadeInAlbumCover()</code> can access it.
+Note: To enable <code>AlbumPage::fadeInAlbumCover()</code> to access <code>albumCover</code>, turn <code>albumCover</code> into a class variable of AlbumPage instead of an internal variable of <code>AlbumPage::createContent()</code>.
 
-Now the only thing left is connecting the <code>appeared()</code> signal to our new <code>fadeInAlbumCover()</code> slot:
+Now you only need to connect the <code>appeared()</code> signal to the new <code>fadeInAlbumCover()</code> slot:
 
 \code
 AlbumPage::AlbumPage(const Album *album, QGraphicsItem *parent)
@@ -228,15 +234,15 @@ AlbumPage::AlbumPage(const Album *album, QGraphicsItem *parent)
 
 \subsection animations_furtherreading Further reading
 
-Multiple animations can be put together into paralallel or sequential animation groups. Animation groups can then be combined to form complex animation hierarchies. On top of that, MParallelAnimationGroup adds styling support for QParallelAnimationGroup, meaning that your animation classes can expose attributes through MeeGo Touch's theming system. Check put-tutorial-on-animations-here for details.
+Multiple animations can be combined into parallel or sequential animation groups which can form complex animation hierarchies. On top of that, MParallelAnimationGroup adds styling support for QParallelAnimationGroup, meaning that your animation classes can expose attributes through MeeGo Touch's theming system. Check put-tutorial-on-animations-here for details.
 
-\section gestures Multi-touch screens and Gestures
+\section gestures Adding support for multipoint touch and gestures
 
-MeeGo Touch supports multi-touch screens. Therefore interactions such as pinching gestures to zoom in and out graphical elements can be easily implemented in MeeGo Touch applications.
+MeeGo Touch supports multipoint touch screens. Therefore, interactions such as pinching gestures to zoom into and out of graphical elements can be easily implemented in MeeGo Touch applications.
 
-As an example on how gestures programming work, we will make the album cover image in the AlbumPage of our Music Catalogue application support pinching gestures. By pinching the cover image you will be able to zoom it in and out.
+The following example illustrates how to include gestures in the applications. In the example, the album cover image in the AlbumPage of our Music Catalogue application is made to support pinching gestures. By pinching the cover image you can zoom in and out.
 
-The first step is to tell the framework that AlbumPage is interested in getting touch events and to subscribe it to receive pinching gestures:
+1. Tell the framework that AlbumPage is interested in getting touch events and subscribe the AlbumPage to receive pinching gestures:
 
 \code
 AlbumPage::AlbumPage(const Album *album, QGraphicsItem *parent)
@@ -248,9 +254,9 @@ AlbumPage::AlbumPage(const Album *album, QGraphicsItem *parent)
 }
 \endcode
 
-Then we need to reimplement the virtual method <code>MWidget::pinchGestureEvent()</code> in order to handle the pinching gestures.
+2. Reimplement the virtual method <code>MWidget::pinchGestureEvent()</code> to handle the pinching gestures. 
 
-Addition to <code>albumpage.h</code>:
+Add the following to <code>albumpage.h</code>:
 \code
 
 class QGestureEvent;
@@ -265,7 +271,7 @@ protected:
 };
 \endcode
 
-Addition to <code>albumpage.cpp</code>:
+Add the following to <code>albumpage.cpp</code>:
 \code
 
 #include <QGestureEvent>
@@ -299,25 +305,25 @@ void AlbumPage::pinchGestureEvent(QGestureEvent *event, QPinchGesture *gesture)
 }
 \endcode
 
-<code>QPinchGesture::scaleFactor()</code> varies around 1.0. Values above 1.0 means that the two fingers on the screen are further away from each other than in the moment the gesture started, thus we're stretching the image (zooming in). Values below 1.0 means the the two fingers are closer to each other than in the moment the gesture started, thus we're shrinking the image (zooming out). The scaleFactor() is always relative to the state when the gesture started.
+<code>QPinchGesture::scaleFactor()</code> varies around 1.0. Values above 1.0 mean that the two fingers on the screen are further away from each other than when the gesture started. This causes the image to be stretched (zooming in). Values below 1.0 mean that the two fingers are closer to each other than when the gesture started, which causes the image to be shrunk (zooming out). The scaleFactor() is always relative to the state when the gesture started.
 
 \subsection gestures_furtherreading Further reading
 
-There are other gestures besides pinching and it's also possible to define new types of gestures. Check Qt's gestures framework documentation.
+You can also define other types of gestures besides pinching. For more information, see Gestures framework documentation of Qt.
 
-\section tutorial_styling Styling
+\section tutorial_styling Styling the application
 
-MeeGo Touch provides a powerful styling engine for applications to customize their look & feel. You can specify things such as widget sizes, alignments, background images and input feedback effects via CSS (Cascading Style Sheets) files.
+MeeGo Touch provides a powerful styling engine for applications to customise their look and feel. You can specify, for instance, widget sizes, alignments, background images, and input feedback effects with CSS (Cascading Style Sheets) files.
 
-MeeGo Touch also has themes, thus the look & feel can change completely from theme to theme. Applications can customize their look & feel for specific themes and/or the base one (meaning that the custom styling will be applied to the application regardless of what's the current theme).
+Since MeeGo Touch also has themes, the look and feel can change completely from theme to theme. Applications can customise their look and feel for specific themes and/or the base one. This means that the custom styling is applied to the application regardless of the current theme.
 
-Let's change the background image of our Music Catalogue application pages. Instead of using the background image provided by the current theme we will specify our own. To make things more interesting we will set one background to be used when our pages are in landscape orientation and another one for when they're in portrait.
+This example illustrates how to change the background image of the Music Catalogue application pages. Instead of using the background image provided by the current theme, a new image is specified. To make things more interesting one background is set to be used when the pages are in landscape orientation and another one when they are in portrait orientation.
 
-To achieve this wee need provide two files:
-   - A CSS file telling MeeGo Touch that our application pages will use different background images.
-   - The file (or files) with our custom background images.
+To achieve this, the following files are needed:
+   - A CSS file telling MeeGo Touch that the application pages use different background images.
+   - The file (or files) with the custom background images.
 
-Create a css file with the same name as the binary file of the app. In our case it will be <code>tutorial_music_catalogue.css</code>. Its content will be the following:
+1. Create a CSS file with the same name as the binary file of the application. In this example, it is <code>tutorial_music_catalogue.css</code>. Its content are as follows:
 
 \code
 MApplicationPageStyle.Landscape {
@@ -329,32 +335,30 @@ MApplicationPageStyle.Portrait {
 }
 \endcode
 
-MeeGo Touch supports both vector (SVG files) and raster images (such as JPEG or PNG files). In this example we explain how to use an SVG image.
+2. MeeGo Touch supports both vector (SVG files) and raster images (such as JPEG or PNG files). This example illustrates how to use an SVG image.
 
-Create an SVG file containing two rectangles: one whose id is "music-catalogue-background-landscape" and the other "music-catalogue-background-portrait". MeeGo Touch uses the SVG id attribute to identify SVG elements, not the name of the SVG file itself. Apply different colors or gradients to those two rectangles. Their proportions are not important as MeeGo Touch will resize them appropriately.
+Create an SVG file containing two rectangles: one whose ID is "music-catalogue-background-landscape" and the other "music-catalogue-background-portrait". MeeGo Touch uses the SVG ID attribute to identify SVG elements, not the name of the SVG file itself. Apply different colours or gradients to those two rectangles. Their proportions are not important as MeeGo Touch resizes them appropriately.
 
-\note If you don't have an SVG editor you can download Inkscape from http://www.inkscape.org/ or simply use the SVG file from the finished example mentioned in the beginning of this document.
+\note If you do not have an SVG editor you can download Inkscape from http://www.inkscape.org/ or simply use the SVG file from the finished example mentioned at the beginning of this document.
 
-Now we have to put those two files in a location where MeeGo Touch can find them. To get them applied to a given application in all themes the locations are:
+Put the two files in a location where MeeGo Touch can find them. To apply them to a given application in all themes, the available locations are:
 
 \verbatim
 <system-theme-directory>/base/meegotouch/<application-binary-name>/style/<application-binary-name>.css
 <system-theme-directory>/base/meegotouch/<application-binary-name>/svg/*.svg
 \endverbatim
 
-Thus for our application, in a linux system, those locations will be:
+Thus, for the example application, in a Linux system, locations are:
 
 \verbatim
 /usr/share/themes/base/meegotouch/tutorial_music_catalogue/style/tutorial_music_catalogue.css
 /usr/share/themes/base/meegotouch/tutorial_music_catalogue/svg/tutorial_music_catalogue.svg
 \endverbatim
 
-After that the pages of your application should have the backgrounds depicted in the SVG file. If they happen to get bright red backgrounds instead it means that MeeGo Touch wasn't able to find the resources specified in your CSS. If nothing changes at all it might mean that your CSS file wans't even found in the first place.
-
-That completes the tutorial.
+After that, the pages of your application should have the backgrounds depicted in the SVG file. If bright red backgrounds are shown instead, MeeGo Touch was not able to find the resources specified in your CSS. If nothing changes at all, MeeGo Touch may not have been able to find your CSS file.
 
 \subsection tutorial_styling_furtherreading Further reading
 
-Read the \subpage styling "Styling" page for more information.
+For more information, see the \subpage styling "Styling".
 
 */