English 5th: Various text corrections

sources/29-web2py-english/01.markmin

@@ -307,7 +307,7 @@ web2py is composed of the following components:
 web2py is distributed in source code, and in binary form for Microsoft Windows and for Mac OS X.
 
 The source code distribution can be used in any platform where Python runs and includes the above-mentioned components.
-To run the source code, you need Python 2.5 or 2.7 pre-installed on the system. You also need one of the supported database engines installed.
+To run the source code, you need Python 2.5, 2.6 or 2.7 pre-installed on the system. You also need one of the supported database engines installed.
 For testing and light-demand applications, you can use the SQLite database, included with Python 2.7.
 
 The binary versions of web2py (for Windows and Mac OS X) include a Python 2.7 interpreter and
@@ -329,7 +329,7 @@ This book includes the following chapters, besides this introduction:
 - Chapter 5 is a reference for the template language used to build views. It shows how to embed Python code into HTML, and demonstrates the use of helpers (objects that can generate HTML).
 - Chapter 6 covers the Database Abstraction Layer, or DAL. The syntax of the DAL is presented through a series of examples.
 - Chapter 7 covers forms, form validation and form processing. FORM is the low level helper for form building. SQLFORM is the high level form builder. In Chapter 7 we also discuss Create/Read/Update/Delete (CRUD) API.
-- Chapter 8 covers communication with as sending emails and SMSes.
+- Chapter 8 covers communication features as retrieving and sending emails and SMSes.
 - Chapter 9 covers authentication, authorization and the extensible Role-Based Access Control mechanism available in web2py. Mail configuration and CAPTCHA are also discussed here, since they are used for authentication. In the third edition of the book we have added extensive coverage of integration with third-party authentication mechanisms such as OpenID, OAuth, Google, Facebook, LinkedIn, etc.
 - Chapter 10 is about creating web services in web2py. We provide examples of integration with the Google Web Toolkit via Pyjamas, and with Adobe Flash via PyAMF.
 - Chapter 11 is about web2py and jQuery recipes. web2py is designed mainly for server-side programming, but it includes jQuery, since we have found it to be the best open-source JavaScript library available for effects and Ajax. In this chapter, we discuss how to effectively use jQuery with web2py.
@@ -349,7 +349,7 @@ This book has been written using the markmin syntax and automatically converted
 ### Support
 
 The main support channel is the usergroup``usergroup``:cite, with dozens of posts every day. Even if you're a newbie, don't hesitate to ask - we'll be pleased to help you.  
-There is also a formal issue tracker system on http://code.google.com/p/web2py/issue . Last but not least, you can have professional support (see the web site for details). 
+There is also a formal issue tracker system on http://code.google.com/p/web2py/issues . Last but not least, you can have professional support (see the web site for details). 
 
 ### Contribute
 
@@ -393,7 +393,7 @@ In all the examples of this book, web2py keywords are shown in bold, while strin
 ### License
 ``license``:inxx
 
-web2py is licensed under the LGPL version 3 License. The full text of the license if available in ref.``lgpl3``:cite.
+web2py is licensed under the LGPL version 3 License. The full text of the license is available in ref.``lgpl3``:cite.
 
 In accordance with LGPL you may:
 
@@ -426,7 +426,7 @@ PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
 **Earlier versions**
 
 Earlier versions of web2py, 1.0.*-1.90.*, were released under the GPL2 license plus a
-commercial exception which, for practical purposes, was very similar to the current LPGLv3.
+commercial exception which, for practical purposes, was very similar to the current LGPLv3.
 
 **Third party software distributed with web2py**
 

sources/29-web2py-english/03.markmin

@@ -1419,7 +1419,7 @@ Here @````//// stands for
 
 but "app", "controller", and "function" are omitted thus assuming default.
 
-Similarly you can use the wiki menu to upload a media file (for example an image) linked to the page. The "manage media" page will show all files you have uploaded and will show the proper expression to link the media file. If, for example you upload a file "test.jpg" with title "beach", the link expression will something like:
+Similarly you can use the wiki menu to upload a media file (for example an image) linked to the page. The "manage media" page will show all the files you have uploaded and will also show the proper expression to link the media file. If, for example you upload a file named "test.jpg" with title "beach", the link expression will be something like:
 
 ``
 \@////15/beach.jpg
@@ -1438,7 +1438,7 @@ If you create a page with slug "wiki-menu" page it will be interpreted as a desc
 ``
 - Home > \@////index
 - Info > \@////info
-- web2py > http://google.com
+- web2py > http://www.web2py.com
 - - About us > \@////aboutus
 - - Contact us > \@////contactus
 ``
@@ -1826,7 +1826,7 @@ Mind that this mechanism still assumes all users are trusted. All the apps creat
 
 #### Mobile **admin**
 
-Notice that the admin application includes "plugin_jqmobile" which packages jQuery Mobile. When admin is accessed from a mobile device; this is detected by web2py and the interface is displayed using a mobile-friendly layout:
+Notice that the admin application includes "plugin_jqmobile" which packages jQuery Mobile. When admin is accessed from a mobile device, this is detected by web2py and the interface is displayed using a mobile-friendly layout:
 
 [[image @///image/mobile.png center 306px]]
 

sources/29-web2py-english/04.markmin

@@ -1003,15 +1003,15 @@ Also notice the ``request.env.wsgi_*`` variables. They are specific to the wsgi
 - ``response.status``: the HTTP status code integer to be passed to the response. Default is 200 (OK).
 - ``response.stream(file, chunk_size, request=request, attachment=False, filename=None, headers=None)``: when a controller returns it, web2py streams the file content back to the client in blocks of size ``chunk_size``. The ``request`` parameter is required to use the chunk start in the HTTP header. ``file`` should be a file path (for backward compatibility, it can also be an open file object, but this is not recommended). As noted above, ``response.download`` should be used to retrieve files stored via an upload field. ``response.stream`` can be used in other cases, such as returning a temporary file or StringIO object created by the controller. If ``attachment`` is True, the Content-Disposition header will be set to "attachment", and if ``filename`` is also provided, it will be added to the Content-Disposition header as well (but only when ``attachment`` is True). If not already included in ``response.headers``, the following response headers will be set automatically: Content-Type, Content-Length, Cache-Control, Pragma, and Last-Modified (the latter three are set to allow browser caching of the file). To override any of these automatic header settings, simply set them in ``response.headers`` before calling ``response.stream``.
 - ``response.subtitle``: optional parameter that may be included in the views. It should contain the subtitle of the page.
-- ``response.title``: optional parameter that may be included in the views. It should contain the title of the page and should be rendered by the HTML title TAG in the header.
+- ``response.title``: optional parameter that may be included in the views. It should contain the title of the page and should be rendered inside the html title tag in the header.
 - ``response.toolbar``: a function that allows you to embed a toolbar into page for debugging purposes ``{{=response.toolbar()}}``. The toolbar displays request, response, session variables and database access time for each query.
-- ``response._vars``: this variable is accessible only in a view, not in the action. It contains the value returned by the action to the view.
+- ``response._vars``: this variable is accessible only in a view, not in the action. It contains the values returned by the action to the view.
 - ``response._caller``: this is a function that wraps all action calls. It defaults to the identity function, but it can be modified in order to catch special types of exception to do extra logging;
   ``
   response._caller = lambda f: f()
   ``
-- ``response.optimize_css``: if can be set to "concat,minify,inline" to concatenate, minify and inline the CSS files included by web2py.
-- ``response.optimize_js``: if can be set to "concat,minify,inline" to concatenate, minify and inline the JavaScript files included by web2py.
+- ``response.optimize_css``: it can be set to "concat,minify,inline" to concatenate, minify and inline the CSS files included by web2py.
+- ``response.optimize_js``: it can be set to "concat,minify,inline" to concatenate, minify and inline the JavaScript files included by web2py.
 - ``response.view``: the name of the view template that must render the page. This is set by default to:
   ``
   "%s/%s.%s" % (request.controller, request.function, request.extension)
@@ -1125,8 +1125,7 @@ In the "generic.html" view this is done using ``{{=response.toolbar()}}``.
 
 #### Separate sessions
 
-If you are storing sessions on filesystems and you have lots of them, the file system access may become a bottle-neck. One solution is the following:
-If you are storing sessions on filesystem and you have lots of them, the file system access may become a bottle-neck. One solution is the following:
+If you are storing sessions on the filesystem and you have lots of them, the file system access may become a bottle-neck. One solution is the following:
 ``
 session.connect(request, response, separate=True)
 ``:code
@@ -1246,7 +1245,7 @@ cache.ram(key, None)
 
 where ``key`` is the key of the cached item.
 
-It is also possible to define other caching mechanisms such as memcache. Memcache is available via ``gluon.contrib.memcache`` and is discussed in more details in Chapter 14.
+It is also possible to define other caching mechanisms such as memcache. Memcache is available via ``gluon.contrib.memcache`` and is discussed in more detail in Chapter 14.
 
 ------
 Be careful when caching to remeber that caching is usually at the app-level not at the user level. If you need, for example, to cache user specific content, choose a key that includes the user id.
@@ -1586,7 +1585,7 @@ a = T("hello %(name)s") % dict(name='Tim')
 The latter syntax is recommended because it makes translation easier.
 The first string is translated according to the requested language file and the ``name`` variable is replaced independently of the language.
 
-You can concatenating translated strings and normal strings:
+You can concatenate translated strings and normal strings:
 ``
 T("blah ") + name + T(" blah")
 ``:code
@@ -1641,7 +1640,7 @@ It is possible to disable lazy evaluation via
 T.lazy = False
 ``:code
 
-In this way, strings are translated immediately by the ``T`` operator based on the currently accepted or forced language.
+In this way, strings are translated inmediately by the ``T`` operator based on the currently accepted or forced language.
 
 It is also possible to disable lazy evaluation for individual strings:
 
@@ -1721,7 +1720,7 @@ Now the PS is activated for the word "book" and for the number 10.
 The result in English will be: "You have 10 books". Notice that "book" has been pluralized into "books".
 
 The PS consists of 3 parts:
-- placeholders ``%%{}`` to mark words in ``T``-messages
+- placeholders ``%%{}`` to mark words in the ``T`` input
 - rule to give a decision which word form to use ("rules/plural_rules/*.py")
 - dictionary with word plural forms ("app/languages/plural-*.py")
 
@@ -1730,7 +1729,7 @@ The value of symbols can be a single variable, a list/tuple of variables, or a d
 The placeholder ``%%{}`` consists of 3 parts:
 
 ``
-%%{[<modifier>]<world>[<parameter>]},
+%%{[<modifier>]<word>[<parameter>]},
 ``
 
 where:
@@ -2233,7 +2232,7 @@ A manual approach consists of creating subfolders for different versions of stat
 
 This procedure works but it is pedantic since every time you update the css file, you must remember to move it to another folder, change the URL of the file in your layout.html and deploy.
 
-Static asset management solves the problem by allowing the developer to declare a version for a group of static files and they will be requested again only when the version number changes. The version number of made part of the file url as in the previous example. The difference from the previous approach is that the version number only appears in the URL, not in the file system.
+Static asset management solves the problem by allowing the developer to declare a version for a group of static files and they will be requested again only when the version number changes. The asset version number is made part of the file url as in the previous example. The difference from the previous approach is that the version number only appears in the URL, not in the file system.
 
 
 If you want to serve "/myapp/static/layout.css" with the cache headers, you just need to include the file with a modified URL that includes a version number:
@@ -2322,7 +2321,7 @@ app/cron/crontab
 It follows the syntax defined in ref. ``cron``:cite (with some extensions that are specific to web2py).
 
 ------
-Before web2py 2.1.1, cron was enabled by default and could be disabled with the ``-N`` command line option, Since 2.1.1, cron is disabled by default and can be enabled by the ``-Y`` option. This change was motivated by the desire to push users toward using the new scheduler (which is superior to the cron mechanism) and also because cron may impact on performance.
+Before web2py 2.1.1, cron was enabled by default and could be disabled with the ``-N`` command line option. Since 2.1.1, cron is disabled by default and can be enabled by the ``-Y`` option. This change was motivated by the desire to push users toward using the new scheduler (which is superior to the cron mechanism) and also because cron may impact on performance.
 ------
 
 This means that every application can have a separate cron configuration and that cron config can be changed from within web2py without affecting the host OS itself.
@@ -2342,7 +2341,7 @@ The last two lines in this example use extensions to regular cron syntax to prov
 The file "applications/admin/cron/expire_sessions.py" actually exists and ships with the **admin** app. It checks for expired sessions and deletes them. "applications/admin/cron/crontab" runs this task hourly.
 -------
 
-If the task/script is prefixed with an asterisk (``*``) and ends with ``.py``, it will be executed in the web2py environment. This means you will have all the controllers and models at your disposal. If you use two asterisks (``**``), the ``MODEL``s will not be executed. This is the recommended way of calling, as it has less overhead and avoids potential locking problems.
+If the task/script is prefixed with an asterisk (``*``) and ends with ``.py``, it will be executed in the web2py environment. This means you will have all the controllers and models at your disposal. If you use two asterisks (``**``), the models will not be executed. This is the recommended way of calling, as it has less overhead and avoids potential locking problems.
 
 Notice that scripts/functions executed in the web2py environment require a manual ``db.commit()`` at the end of the function or the transaction will be reverted.
 
@@ -2484,11 +2483,9 @@ Let's see them in order:
 ------
 NB: This is useful if you have different workers instances (e.g. on different machines) and you want to assign tasks to a specific worker.
 
-NB2: It's possible to assign a worker more groups, and they can be also all the same, as
+NB2: It's possible to assign a worker more groups, and they can be also all the same, as ``['mygroup','mygroup']``. Tasks will be distributed taking into consideration that a worker with group_names ``['mygroup','mygroup']`` is able to process the double of the tasks a worker with group_names ``['mygroup']`` is.
 ------
-``['mygroup','mygroup']``. Tasks will be distributed taking into consideration that
-a worker with group_names ``['mygroup','mygroup']`` is able to process the double of the tasks
-a worker with group_names ``['mygroup']`` is.
+
 - ``heartbeat`` is by default set to 3 seconds. This parameter is the one controlling how often a scheduler will check its status on the ``scheduler_worker`` table and see if there are any **ASSIGNED** tasks to itself to process.
 - ``max_empty_runs`` is 0 by default, that means that the worker will continue to process tasks as soon as they are **ASSIGNED**. If you set this to a value of, let's say, 10, a worker will die automatically if it's **ACTIVE** and no tasks are **ASSIGNED** to it for 10 loops. A loop is when a worker searches for tasks, every 3 seconds (or the set ``heartbeat``)
 - ``discard_results`` is False by default. If set to True, no scheduler_run records will be created.
@@ -2624,7 +2621,7 @@ A call to ``scheduler.queue_task`` returns the task ``id`` and ``uuid`` of the t
 <Row {'errors': {}, 'id': 1, 'uuid': '08e6433a-cf07-4cea-a4cb-01f16ae5f414'}>
 ``
 
-If there are errors (usually syntax error os input validation errors),
+If there are errors (usually syntax errors or input validation errors),
 you get the result of the validation, and id and uuid will be None
 
 ``
@@ -2651,7 +2648,8 @@ In any case, the stdout is captured and also logged into the run record.
 
 Using appadmin, one can check all ``RUNNING`` tasks, the output of ``COMPLETED`` tasks, the error of ``FAILED`` tasks, etc.
 
-The scheduler also creates one more table called "scheduler_worker", which stores the workers' heartbeat and their status. Possible worker statuses are:
+The scheduler also creates one more table called "scheduler_worker", which stores the workers' heartbeat and their status. 
+
 
 ##### Managing processes
 
@@ -2723,8 +2721,8 @@ The scheduler is considered experimental because it needs more extensive testing
 
 A special "word" encountered in the print statements of your functions clear all
 the previous output. That word is ``!clear!``.
-This, coupled with the ``sync_output`` parameter, allows to report percentages
-a breeze. 
+This, coupled with the ``sync_output`` parameter, allows to report percentages.
+
 
 Here is an example:
 
@@ -2829,7 +2827,13 @@ There are many ways applications can cooperate:
 - Applications can call each other's actions locally using ``exec_environment`` as discussed above.
 - Applications can import each other's modules using the syntax:
 ``
-from applications.appname.modules import mymodule
+from applications.otherapp.modules import mymodule
+``:code
+
+or
+
+``
+import applications.otherapp.modules.othermodule
 ``:code
 
 - Applications can import any module in the ``PYTHONPATH`` search path, ``sys.path``.
@@ -2842,11 +2846,6 @@ session.connect(request, response, masterapp='appname', db=db)
 
 Here "appname" is the name of the master application, the one that sets the initial session_id in the cookie. ``db`` is a database connection to the database that contains the session table (``web2py_session``). All apps that share sessions must use the same database for session storage.
 
-One application can load a module from another app using
-
-``
-import applications.otherapp.modules.othermodule
-``:code
 
 ### Logging