com web/doc: Minor cosmetic amendments to the tutorial: tutorial/builds.md tutorial/editing.md tutorial/faq.md tutorial/intro.md tutorial/joining.md tutorial/structure.md tutorial/style.md tutorial/translating.md

diff --git a/tutorial/builds.md b/tutorial/builds.md
index 8a7bdac..76b8fde 100644
--- a/tutorial/builds.md
+++ b/tutorial/builds.md
@@ -1,34 +1,50 @@
 # The PHP Manual builds
 
-The PHP Manual is written in DocBook and built by PhD, and these builds are rsynced to the mirrors for users to use.
+The PHP Manual is written in [DocBook][docbook] and built by [PhD][phd], and
+these builds are rsynced to the mirrors for users to use.
 
 ## Mirror builds
-The [rsync box](https://wiki.php.net/systems/sc1) builds the manuals each week, at 10:46 UTC on Fridays. 
-The mirrors then pickup these builds when they sync, which usually happens every hour.  When mirrors sync 
-depends on how their cron is setup.
+The [rsync box][rsync.php.net] builds the manuals each week, at 10:46 UTC on Fridays.
+The mirrors then pick up these builds when they sync, which usually happens every hour.
+When a mirror syncs depends on how its cron is set up.
 
 ## Doc server builds
-The [documentation server](http://doc.php.net) builds and displays the manual four times daily (0:15 6:15 12:15
-and 18:15 UTC). This takes place on the [euk2](https://wiki.php.net/systems/euk2) server. The simplest way to see
-when each translation last built, see the [doc downloads page with dates](http://docs.php.net/download-docs.php?sizes=1).
-Also note that several old translations reside on this server, as it attempts to build every translation
-(both active and inactive).
+The [docs development server][docs.php.net] builds the manual four times a day
+(0:15 6:15 12:15 and 18:15 UTC). This takes place on the [euk2][euk2] server.
+An easy way to see when each translation was last built, is to look at the
+[doc downloads page with dates][download-docs]. Also note that several old
+translations reside on this particular server, as it attempts to build every
+translation (both active and inactive).
 
 ## CHM builds
-The CHM version of the manual is built on a Windows machine and are pulled weekly on Fridays. Richard maintains
-these builds. Due to the security profile on the Windows machine, rsync is not used. Instead, a normal HTTP request
-is used.
+The CHM version of the manual is built on a Windows machine and pulled on Fridays,
+for distribution to mirrors. [Richard][rquadling] maintains these builds.
 
 ## Validation
-Aside from running `php configure.php –with-lang=foo` for a language, another way to check if manuals validated is
-by looking at build dates on the doc server. See this list of [downloadable docs](http://docs.php.net/download-docs.php?sizes=1)
-for more information. These include the dates that the manual for each language successfully built.
+Aside from running `php configure.php –with-lang=foo` (see [editing](editing.md))
+for a language, another way to check if the docs validated is by looking at build
+dates on the doc server. See "Doc server builds", above.
 
 ## Additional notes
-- If a manual does not validate on Friday, it will not be pushed to the mirrors until hopefully the upcoming Friday.
-- Only active translations are selectable/downloadable, and this is managed in [phpweb/includes/languages.inc](http://git.php.net/?p=web/php.git;a=blob;f=include/languages.inc)
+- If a manual does not validate on Friday, it will not be pushed to the mirrors
+  until it does validate (hopefully, the upcoming Friday).
+- Only active translations are selectable/downloadable, and this is managed in
+  [phpweb/includes/languages.inc][languages.inc]
 
 ## The humans who manage these
-If there is a problem with the synced builds, it's wise to contact [Derick](http://people.php.net/derick) or 
-[Hannes](http://people.php.net/bjori). If a problem exists on the developmental server (docs.php.net),
-then contact the documentation team.
\ No newline at end of file
+If there is a problem with the synced builds, it's wise to contact
+[Derick][derick] or [Hannes][bjori].
+If a problem exists on the development server ([docs.php.net][docs.php.net]),
+then contact the documentation team.
+
+[docbook]: http://www.docbook.org/
+[phd]: http://doc.php.net/phd.php
+[rsync.php.net]: https://wiki.php.net/systems/sc1
+[docs.php.net]: http://docs.php.net
+[euk2]: https://wiki.php.net/systems/euk2
+[download-docs]: http://docs.php.net/download-docs.php?sizes=1
+[fetch-chms]: http://svn.php.net/viewvc/phpdoc/doc-base/trunk/scripts/fetch-chms.php?view=markup
+[languages.inc]: http://git.php.net/?p=web/php.git;a=blob;f=include/languages.inc
+[rquadling]: http://people.php.net/rquadling
+[derick]: http://people.php.net/derick
+[bjori]: http://people.php.net/bjori
diff --git a/tutorial/editing.md b/tutorial/editing.md
index 1f898f3..bf6b94d 100644
--- a/tutorial/editing.md
+++ b/tutorial/editing.md
@@ -1,21 +1,20 @@
 # Editing manual sources
 
 ## Introduction
-When editing or translating manual you have to remember some things:
+When editing or translating the manual, you have to remember some things:
 - use only UTF-8 encoding
-- follow [style guidelines](style.md)
+- follow the project's [style guidelines](style.md)
 
 ## Editing existing documentation
 Simply open the files and edit them.
 
 ## Adding new documentation
-When adding new functions or methods, there are a couple of options. Either way, the generated (or copied) files
-will need to be filled out.
+When adding new functions or methods, there are a couple of options.
 
 ### Option A: Generating files using docgen
-This is preferred way to generate files for new functions or methods. The `docgen` script is found within 
-the PHP documentation (phpdoc/scripts/docgen/) and uses Reflection to generate documentation (DocBook) files.
-Fill in skeleton files before you commit them!
+This is preferred way to generate files for new extensions, classes, functions
+or methods using [`docgen`][docgen]. The script is found in the [doc-base][doc-base]
+repository and uses reflection to generate documentation (DocBook) files.
 
 ### Option B: Copy skeleton files
 This involves copying the skeleton files into the correct location:
@@ -24,33 +23,44 @@ cp /phpdoc/RFC/skeletons/method.xml classname/methodname.xml   #for new methods
 cp /phpdoc/RFC/skeletons/function.xml functions/functionname.xml #for new functions
 ```
 
-Note: *classname*, *methodname* and *functionname* are lowercased names of the class, method or function, respectively,
-not a literal file name.
+Note: *classname*, *methodname* and *functionname* are lowercased names of the
+class, method, or function, respectively, not a literal file name.
 
-Remember about extension [structure](structure.md) when copying those files.
+Remember the extension folder [structure](structure.md) when copying those files.
 
 ## Translating documentation
-Translation process has been described in [separate chapter](translating.md).
+The translation process is described in the [translating chapter](translating.md).
 
 ## Validating your changes
-Every time you make changes to documentation sources (both English or translation) you have to validate your changes.
-Proper script is distributed with documentation sources, so you already have it in *doc-base* directory. All you have
+Every time you make changes to documentation sources (both English or translation),
+you have to validate your changes to ensure that the manual still builds without error.
+The necessary [configure.php][configure.php] script is distributed with the
+[doc-base][doc-base] repository, so you should already have it. All you have
 to do to validate changes is run configure.php:
 ```
 $ cd phpdoc
 $ php configure.php --with-lang={LANG}
 ```
-If your language is English you can omit whole lang parameter and only execute `php configure.php`. When the above
-outputs something like “All good. Saving .manual.xml… done.” then you know it validates. You can commit your
-changes now.
+If your language is English you can omit the `with-lang` argument. When the above
+outputs something like "All good. Saving .manual.xml… done." then you know it validates.
+You can commit your changes now.
 
 ## Commit changes
-If you have access to SVN, you can commit modified files.
+If you have the appropriate [commit karma][karma], you can commit your modified files.
 
 ## Viewing changes online
-Documentation is builded every Friday. It applies to all formats - online, offline HTML files and CHM. However,
-there is a special mirror - http://docs.php.net/ - where manual is updated from sources every six hours. If any
-errors occured, special message will be delivered to your lang's mailinglist. Read more about manual builds in 
-[dedicated appendix](builds.md).
+Documentation is built every Friday, then synced out to the website mirrors. However,
+there is a special mirror at [docs.php.net][docs] - where the manual is updated
+from sources every six hours. If any errors occured, a message will be delivered
+to the appropriate mailinglist (`doc-{LANG}@lists.php.net`).
 
-Last chapter contains [style guidelines](style.md) you are obliged to follow. Read them carefully.
\ No newline at end of file
+Read more about manual builds in the [builds appendix](builds.md).
+
+The next chapter contains [style guidelines](style.md) that you are obliged to
+follow. Read them carefully.
+
+[docgen]: http://svn.php.net/viewvc/phpdoc/doc-base/trunk/scripts/docgen/
+[doc-base]: http://svn.php.net/viewvc/phpdoc/doc-base/
+[configure.php]: http://svn.php.net/viewvc/phpdoc/doc-base/trunk/configure.php?view=markup
+[karma]: http://svn.php.net/viewvc/SVNROOT/global_avail?view=markup
+[docs]: http://docs.php.net/
diff --git a/tutorial/faq.md b/tutorial/faq.md
index 64ac2ff..c6c7a4f 100644
--- a/tutorial/faq.md
+++ b/tutorial/faq.md
@@ -1,13 +1,20 @@
 # Frequently Asked Questions
 
 ## I'm about to document a new PHP extension. How should I start?
-Change your working directory to `phpdoc/doc-base/scripts/docgen/` and execute following command:
-`$ php docgen.php -e simplexml -o outdir`. It creates the skeletons that you edit then commit.
+Change your working directory to `phpdoc/doc-base/scripts/docgen/` and execute:
+```
+php docgen.php -e simplexml -o outdir
+```
+
+It creates the skeletons that you edit, and then commit.
+
 Help is available with following command: `$ php docgen.php -h`.
 
 ## I created skeletons that contain a bunch of default text, should I commit it?
-No, you can't. Edit files before commit. There are two reasons: translators and the fact that temporary
-often becomes permanent, and bogus text is not good.
+No! Edit the files, to check the generated content and add more information,
+before committing. Thinking that it is okay to commit the skeleton files because
+you will soon come along and flesh them out might seem like a good idea. However,
+temporary often becomes permanent.
 
 ## Running configure.php ends up segfaulting, what is up?
 There are bugs with certain versions of libxml that cause this, so hacks exist to get around it.
@@ -16,42 +23,45 @@ Note: This disables some error checking and beautification but raw errors will b
 Note: Usually the problem is a major XML syntax issue.
 
 ## Is there an online editor?
-Yes, just go to https://edit.php.net
+Yes, just go to [edit.php.net](https://edit.php.net).
 
 ## How do I add a link to a method?
-Use `<methodname>Class::Method</methodname>` Note that the case does not matter when adding a link.
+Use `<methodname>Class::method</methodname>`. Note that the case does not matter when adding a link.
 
 ## If a refentry should not emit versioning information, what should I do?
-Add the `role="noversion"` to its `<refentry>`. Example: `<refentry xml:id="reserved.variables.argc" xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" role="noversion//">`
+Add the `role="noversion"` to its `<refentry>`. Example:
+```
+<refentry xml:id="reserved.variables.argc" xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" role="noversion">
+```
 
 ## How do I add an external link to the documentation?
 All external links are added to `doc-base/entities/global.ent`. Markup looks as follows:
 ```
 <!ENTITY spec.google "http://www.google.com/">
 ```
-Then you can use this syntax in documentation:
+Then you can use this syntax in the documentation:
 ```
 <link xlink:href="&spec.google;">google spec</link>
 ```
-Be sure the file understands the namespace with `xmlns:xlink="http://www.w3.org/1999/xlink"` in the root element.
+Be sure the file understands the `xlink` namespace, by using `xmlns:xlink="http://www.w3.org/1999/xlink"` in the document element.
 
 ## When adding a note, should I add a title?
-Typically titles are useful for notes, but it's not required. Syntax as follows:
+Typically titles are useful for notes, but it's not required.
 ```
 <note>
- <title>foo</title>
- <para>note contents</para>
+ <title>Foo</title>
+ <para>Note contents are here.</para>
 </note>
 ```
 
 ## A feature became available in PHP X.Y.Z, how do I document that?
-Version information for functions is stored inside `versions.xml` within each extension: `phpdoc/en/extname/version.xml`
-Changes to functions, like added parameters, are documented within changelogs for each page
-Example text: *Feature X has been available since PHP X.Y.Z*.
+Version information for functions is stored inside `versions.xml` within
+each extension (e.g. `phpdoc/en/extname/version.xml`). Changes to functions,
+like added parameters, are documented within the changelog section for each page.
 
 ## A parameter is optional, how is it documented?
-Like normal, except `methodparam` receives the `choice="opt"` attribute, and the `<initializer>` tag is used
-to signify the default value. Example syntax:
+Like normal, except `methodparam` receives the `choice="opt"` attribute, and
+the `<initializer>` tag is used to signify the default value.
 ```
 <methodparam choice="opt"><type>bool</type><parameter>httponly</parameter><initializer>false</initializer></methodparam>
 ```
@@ -82,4 +92,4 @@ Examples: `entities/file-entities.ent` and `en/reference/foo/entities.bar.xml`
 ## What .subversion/config settings should I have set?
 ```
 *.xml = svn:eol-style=native;svn:keywords=Id Rev Revision Date LastChangedDate LastChangedRevision Author LastChangedBy HeadURL URL
-```
\ No newline at end of file
+```
diff --git a/tutorial/intro.md b/tutorial/intro.md
index 3adcc75..b9cec98 100644
--- a/tutorial/intro.md
+++ b/tutorial/intro.md
@@ -1,23 +1,26 @@
 # PHP Manual Contribution Guide
-This document is in very early stage of development. If you are a newcomer, please look at already existing resources.
-More experienced users are welcome to contribute.
+This document is in the very early stages of development. If you are a newcomer,
+please look at already existing resources.
+
+More experienced users are welcome to [contribute](http://git.php.net/?p=web/doc.git;a=tree;f=tutorial).
 
 ## Introduction
-PHP is well known for having excellent documentation, documentation that is created by volunteers who
+PHP is well known for having excellent documentation. Documentation that is created by volunteers who
 collectively make changes every day. This guide is designed for people who work on the official PHP documentation.
 
 ## Glossary
-This guide use some terminology you have to know. Don't worry, it's easy:
-- **editor** - person who contributes to original the English manual
+This guide uses some terminology that you have to know. Don't worry, it's easy:
+- **author** - person who contributes to original the English manual
 - **translator** - person who translates the English manual into another language
-- **{LANG}** - replace it with your two-letter country code, in example in mailing list address (note: Brazilian Portuguese
-format differs from the rest and it's called *pt_BR* for SVN module and *pt-br* for mailing list sufix). If you edit
-original PHP Manual your language code is *en*.
+- **{LANG}** - replace it with your two-letter country code, (e.g. when refering
+  to a mailinglist, `doc-{LANG}@lists.php.net`). Note: Brazilian Portuguese differs
+  from the rest and it's called *pt_BR* for the SVN module and *pt-br* for the
+  mailing list suffix.
 
 ## Table of Contents
 - [Joining the team](joining.md)
 - [Documentation structure](structure.md)
-- [Editing PHP Manual](editing.md)
+- [Editing the PHP Manual](editing.md)
 - [Translating documentation](translating.md)
 - [Style guidelines](style.md)
 
diff --git a/tutorial/joining.md b/tutorial/joining.md
index 92fe49c..e5dc135 100644
--- a/tutorial/joining.md
+++ b/tutorial/joining.md
@@ -1,28 +1,36 @@
 # Joining the team
-Joining the PHP Documentation team is a simple process, but a process nonetheless. It can be summarized as:
+Joining the PHP Documentation team is a simple process, but a process nonetheless.
+It can be summarized as:
 
-## Write a list
-Because official communication is done there, you should write the proper list. Say “Hi” and what you're interested
-in doing. You may feel more comfortable lurking for awhile, or reading the archives, or hanging out in IRC
-(#php.doc on Efnet) for awhile, but ultimately let the list know who you are.
+## Write to a mailing list
+Because official communication is done there, you should write to the proper list.
+Say "Hi" and what you're interested in doing. You may feel more comfortable lurking
+for a while, or reading the archives, or hanging out in IRC (#php.doc on Efnet)
+for a while, but ultimately let the list know who you are.
 
-### For editors
-You should send your message to `[email protected]` mailinglist.
+### For authors
+You should send your message to the `[email protected]` mailing list.
 
 ### For translators
-You should send your message to `doc-{LANG}@lists.php.net` mailinglist.
+You should send your message to the appropriate `doc-{LANG}@lists.php.net` mailing list.
 
 ## Create a doc patch or three
-This step is required to show us that you are a real human, you want to do some work and in general know how to do this.
+This step is required to show us that you are a real human, you want to do
+some work and in general know how to do this.
 
-The simplest way to get started is by using  the [Online Documentation Editor](https://wiki.php.net/doc/editor)
-which allows you to login via Facebook/Twitter/Google account and edit documentation. Your patches will be then
-reviewed and accepted by someone with SVN access.
+The simplest way to get started is by using the [Online Documentation Editor](https://edit.php.net)
+which allows you to login via your Facebook/Twitter/Google account and edit the documentation.
+Your patches will be then reviewed and accepted by someone with SVN access.
+
+Our wiki contains an [overview of the editor and how to use it](https://wiki.php.net/doc/editor).
 
 ## Obtaining SVN access
-If you plan to contribute to manual regularly and want to do this more efficiently, you probably would like to 
-use SVN directly. To request for PHP.net account, please fill in [this form](http://php.net/git-php.php). Provide links
-to your commits or list your patches on textarea field. Basically, tell us what have done, to prove that you really
-need this account.
+If you plan to contribute to the manual regularly, and want to do this more efficiently,
+you probably would like to use SVN directly. This requires a PHP.net account.
+
+To request one, please fill in [this form](http://php.net/git-php.php). 
+
+Provide links to your work that has already been committed and/or list your current patches.
+Basically, tell us what have done, to prove that you really need this account.
 
-Next chapter will explain how to get manual sources and how are they [structured](structure.md).
\ No newline at end of file
+The next chapter will explain how to get the manual sources and how are they [structured](structure.md).
diff --git a/tutorial/structure.md b/tutorial/structure.md
index 33dae8b..92f268b 100644
--- a/tutorial/structure.md
+++ b/tutorial/structure.md
@@ -1,36 +1,40 @@
 # Manual sources structure
 
 ## Downloading sources
-PHP Manual sources are currently stored in Subversion (SVN) repository. You don't need SVN access to checkout (download)
-them, but you need it if you want to send your changes to our server.
+The PHP Manual sources are currently stored in our Subversion (SVN) repository.
+You don't need SVN access to checkout (download) the files, but you do need it
+if you want to send your changes to our server.
 
-This tutorial assumes that you have basic knowledge about SVN. If not, you can read {TODO}. In order to checkout manual
-files, use following command:
+This tutorial assumes that you have basic knowledge about SVN.
+If not, you can read [Version Control with Subversion](http://svnbook.red-bean.com/).
+In order to checkout the manual files, use the following command:
 
 ```
 svn checkout https://svn.php.net/repository/phpdoc/modules/doc-{LANG} phpdoc
 ```
 
-This command will create directory named phpdoc, however, the name can be anything you wish. This directory will
-contain folder with sources of your language (named *{LANG}*) and *doc-base* with some helpful tools.
+This command will create a directory named `phpdoc` (the name can be anything you wish).
+This directory will contain a folder with the sources of your chosen language
+(named *{LANG}*) and a *doc-base* folder, which is home to some helpful tools.
 
 ## Files structure
-**Note for translators:** if any of source files doesn't exists in translation, English content will be used
-in building process. This means that you *cannot* place untranslated files in your translation tree. Otherwise,
-it will lead to mess, confusion and may break some tools.
+**Note for translators:** if any of the source files don't exist in your translation, the English content will be used
+during the building process. This means that you *must not* place untranslated files in your translation tree. Otherwise,
+it will lead to a mess, confusion and may break some tools.
 
-Structure of manual sources is rather intuitive. The most complicated part is documentation for extensions
-(which is the biggest part of manual, because all functions are grouped into extensions).
+The structure of the manual sources is hopefully rather intuitive. The most
+complicated part is the documentation for extensions, which is also the biggest
+part of manual as all functions are grouped into extensions.
 
 The documentation for extensions is located in `/phpdoc/{LANG}/reference/extension_name/`.  For example, 
 the calendar extension documentation exists in  `/phpdoc/{LANG}/reference/calendar/`. There you'll find several files:
 - *book.xml* - acts as the container for the extension and contains the preface. Other files (like examples.xml)
 are included from here.
 - *setup.xml* - includes setup, install and configuration documentation
-- *constants.xml* - lists all constants the extension declares, if any
+- *constants.xml* - lists all constants that the extension declares, if any
 - *configure.xml* - usually this information is in setup.xml, but if the file exists it is magically
 included into setup.xml
-- *examples.xml - various examples
+- *examples.xml* - various examples
 - *foo.xml* - example, foo can be anything specific to a topic. Just be sure to include via book.xml.
 
 A procedural extension (like calendar) also has:
@@ -43,4 +47,4 @@ And OO extensions (such as imagick) contain:
 
 Note: *classname* is the lowercased name of the class, not a literal file or directory name.
 
-Next chapter will discuss how to [edit manual sources](editing.md).
\ No newline at end of file
+The next chapter will discuss how to [edit the manual sources](editing.md).
diff --git a/tutorial/style.md b/tutorial/style.md
index 80e1678..b4ff125 100644
--- a/tutorial/style.md
+++ b/tutorial/style.md
@@ -2,15 +2,17 @@
 
 ## Technical requirements
 - All files **must** be encoded using UTF-8 (without BOM)
-- Use only Unix line endings
+- Use only Unix line endings (`\n`)
 
-## Line lenghts
-Please keep every line in XML file 80 characters long. This is loose requirement and 100 is probably acceptable as
-maximum length. This allow to keep *diffs* simple and useful for translators, so follow this rule carefully.
+## Line lengths
+Please aim to keep lines in an XML file around 80 characters long or less.
+This is a loose requirement and 100 is probably acceptable as a maximum length.
+This aids in keeping *diffs* simple, which is particularly useful for translators,
+so follow this rule carefully.
 
 ## Whitespaces
-Indent every block level with one space. Do not use tabs. Only examples are using four spaces as indentation level,
-accordingly to [PEAR Coding Standards](http://pear.php.net/manual/en/standards.php).
+For XML, indent using one space. Do not use tabs. PHP code, in examples, uses
+four spaces for indentation, since the code should adhere to the [PEAR Coding Standards](http://pear.php.net/manual/en/standards.php).
 
 ## Punctuation
 Punctuation in the PHP Manual follows regular grammatical rules. When writing flowing sentences, such as in function
@@ -18,24 +20,24 @@ descriptions, normal punctuation should be used. Lists, titles, and sentence fra
 a period. Sentences need not have two spaces between them. Commas and apostrophes should be used appropriately.
 
 ## Personalization
-The PHP Manual is a technical document, and should be written so. The use of “you” is rampant in the manual,
+The PHP Manual is a technical document, and should be written so. The use of "you" is rampant in the manual,
 and presents an unprofessional image.  The only exceptions to the personalization rule are: the PHP Tutorial and FAQs.
 
 Example:
 ```
-INCORRECT: You can use the optional second parameter to specify tags which should not be stripped.
-CORRECT: The optional second parameter may be used to specify tags which should not be stripped.
+INCORRECT: You can use the optional second parameter to specify tags that should not be stripped.
+CORRECT: The optional second parameter may be used to specify tags that should not be stripped.
 ```
 
 ## Chronology
 - When referring to a specific version of PHP, "since" should not be used. "As of" should be used in this case.
-- In changelogs, newest PHP versions go above the older ones.
-- If changelog entry applies to few PHP versions, separate them by a comma, with the lesser version first.
+- In changelogs, newer PHP versions go above older ones.
+- If a changelog entry applies to multiple PHP versions, separate them by a comma with the lower version first.
 Example: `<entry>5.2.11, 5.3.1</entry>`
 
 ## General Grammar
 The PHP Manual should be written with particular attention to general English grammar. Contractions should be used
-appropriately. Special attention should be applied to sentence construction when using prepositions (ie, sentences
+appropriately. Special attention should be applied to sentence construction when using prepositions (i.e., sentences
 should not end in prepositions).
 
 ## PHP Manual Terms
@@ -58,4 +60,4 @@ superglobals             | super globals, autoglobals
 web server               | webserver
 the foo page (as a link) | click here, go here
 Unix                     | UNIX (it's a registered trademark)
-Windows                  | windows (when referring to Microsoft Windows)
\ No newline at end of file
+Windows                  | windows (when referring to Microsoft Windows)
diff --git a/tutorial/translating.md b/tutorial/translating.md
index 3124893..0db4b08 100644
--- a/tutorial/translating.md
+++ b/tutorial/translating.md
@@ -1,48 +1,59 @@
 # Translating documentation
 
-**Watch out:** this chapter describes special part of whole editing process. You have to follow other steps from
-[editing manual sources](editing.md) section.
+**Watch out:** this chapter describes special parts of the whole editing process.
+You will also have to follow other steps from the [editing manual sources](editing.md) section.
 
-Translating documentation into other languages might look like a complicated process, but in fact, it's rather simple.
-Every file in SVN has *revision*. It is basically current version of specified file. We use revisions to check if file
-is synchronized with English version, so to find out if translation is up-to-date. That's why every file in your
-translation requires EN-Revision comment with following syntax:
-`<!-- EN-Revision: [some number] Maintainer: [username] Status: ready -->`
-The most important part of this comment is revision of English file which translated version is based on. Let's see
-examples:
+Translating documentation into other languages might look like a complicated 
+rocess, but in fact, it's rather simple. 
+
+Every file in SVN has a *revision number*. It is basically the current version of
+the specified file. We use revisions to check if a file is synchronized with its
+English counterpart: to find out if the translation is up-to-date. That's why every
+file in your translation requires an EN-Revision comment with the following syntax:
+```
+<!-- EN-Revision: [some number] Maintainer: [username] Status: ready -->
+```
+The most important part of this comment is the revision number of the English file
+that this translated file is based on. Let's see examples:
 
 ## Translating new file
-You want to translate documentation of `in_array()` function, which doesn't exists in your language yet. Open the file
-`phpdoc/en/reference/array/in-array.xml` and copy number of revision. Sample header might look like this:
+Say you want to translate the documentation of the `in_array()` function, which
+doesn't exist in your language yet. Open the file `phpdoc/en/reference/array/in-array.xml`
+and copy the revision number. The English file's header might look like this:
 ```
 <?xml version="1.0" encoding="utf-8"?>
 <!-- $Revision: 310394 $ -->
 ```
 
-So our number is `310394`. Let's see how your translated file header should look like if we assume that your SVN
-username is *johnsmith*:
+So our revision number is `310394`. Let's see how your translated file header
+should look like if we assume that your SVN username is *johnsmith*:
 ```
 <?xml version="1.0" encoding="utf-8"?>
 <!-- EN-Revision: 310394 Maintainer: johnsmith Status: ready -->
 <!-- $Revision$ -->
 ```
 
-`$Revision` is a kind of macro which will be replaced with number of current revision when you commit your changes.
-Revision number you have copied from English file was created this way.
+`$Revision$` is an SVN keyword, which will be replaced with the number of current
+revision when you commit your changes. The revision number that you have copied
+from the English file was created this way.
 
-The rule is simple: if your revision number is equal to revision number of English file you've translated, it means
-that your translation is up-to-date. Otherwise, it needs to be synced.
+The rule is simple: if your revision number is equal to the revision number of
+the English file you've translated, then your translation is up-to-date.
+Otherwise, it needs to be synced.
 
 ## Updating translation of existing file
-Let's assume you want to update translation of `password_needs_rehash()`. There are two simple ways
-to see which files require update and what have to be changed to sync with English version: using
-[Online Editor](https://edit.php.net) or [doc.php.net tools](http://doc.php.net). Second way is described below.
+Let's assume that you want to update the translation of `password_needs_rehash()`.
+There are two simple ways to see which files require updating and what has to be
+changed to sync with English version: using [Online Editor](https://edit.php.net) 
+or [doc.php.net tools](http://doc.php.net). The second way is described below.
 
-Choose your language from right sidebar and then use "Outdated files" tool. Filter files by directory or username
-(username used here comes from `Mantainer` variable in comment described above). Let's assume that script marked
-`password-needs-rehash.xml` as outdated. Click on filename and you will see *diff* - list of changes between two
-versions of file: your version (current number in EN-Revision in your translation) and newest version in English
-tree. This is sample diff:
+Choose your language from the right sidebar and then use the "Outdated files" tool.
+Filter files by directory or username (username used here comes from the `Mantainer`
+variable in the header comment described above). Let's assume that the tool marked
+`password-needs-rehash.xml` as outdated. Click on the filename and you will see
+*diff* - list of changes between two versions of file: your version (current
+number in EN-Revision in your translation) and newest version in the English source
+tree. The example below should what the diff might look like:
 
 ```
 --- phpdoc/en/trunk/reference/password/functions/password-needs-rehash.xml	2013/06/21 12:24:55	330609
@@ -60,13 +71,17 @@ tree. This is sample diff:
     This function checks to see if the supplied hash implements the algorithm
 ```
 
-First two lines indicate compared revisions. First was taken from your EN-Revision tag and second is current version
-of this file in English. As you can see, there is a difference between two lines. Types of parameters `options` and
-`algo` in function synopsis had been changed from `string` to `integer` and `array`. You have to perform this changes
-in your translation to make it up-to-date. Open `phpdoc/{LANG}/reference/password/functions/password-needs-rehash.xml`
-and change those lines to match English version.
+The first two lines indicate the compared revisions. The first was taken from the
+EN-Revision number and the second is the current version of this file in English.
+
+As you can see, there is a difference between two lines. The `types` for the
+parameters `options` and `algo` in the synopsis had been changed from `string`,
+to `integer` and `array` respectively. You have to perform these changes in your
+translation to make it up-to-date. Open `phpdoc/{LANG}/reference/password/functions/password-needs-rehash.xml`
+and change those lines to match the English version.
 
-Then update EN-Revision number in header. You can also add your credits using CREDITS tag. Your file header might look like this:
+Then update the EN-Revision number in the header comment. You can also add your
+credits using the CREDITS tag. Your file header might look like this initially:
 ```
 <?xml version="1.0" encoding="utf-8"?>
 <!-- EN-Revision: 330609 Maintainer: someone Status: ready -->
@@ -79,7 +94,9 @@ and after changes it should looke like this:
 <!-- $Revision$ -->
 <!-- CREDITS: johnsmith -->
 ```
-Numbers came from diff showed above. If you want to add yourself to credits tag which already exists, separate
-usernames with coma, i.e.: `<!-- CREDITS: george, johnsmith -->`.
+The new EN-Revision number came from the diff shown above. If you want to add
+yourself to a CREDITS tag that already exists, separate
+usernames with a comma, i.e.: `<!-- CREDITS: george, johnsmith -->`.
 
-Finally, your translation is up-to-date. It is quite long process but it's simple and logical when you get used to.
\ No newline at end of file
+Your translation is now up-to-date. It is quite a long process but it's simple
+and logical when you get used to it.