[TASK] Fix typos

Documentation/0-Introduction/3-structure.rst

@@ -3,7 +3,7 @@
 Structure of this book
 ======================
 
-This chapter is structured into ten subchapters and three appendices. The
+This chapter is structured into ten sub chapters and three appendices. The
 chapters discuss the following topics:
 
 Chapter 1, *Installation*, leads you through the

Documentation/1-Installation/1-configuring-the-server.rst

@@ -4,7 +4,7 @@ Configuring the Server
 ======================
 
 Since TYPO3 is written in the PHP scripting language, you will need a
-webserver like Apache with PHP. For the appropriate PHP version, look at "system requirements" at the TYPO3 download page. (*https://get.typo3.org/*) Additionally TYPO3 requires a SQL database for data storage.
+web server like Apache with PHP. For the appropriate PHP version, look at "system requirements" at the TYPO3 download page. (*https://get.typo3.org/*) Additionally TYPO3 requires a SQL database for data storage.
 If you don't have a local development server yet, we recommend the XAMPP
 package (*http://www.apachefriends.org/xampp.html*). It
 will install Apache, PHP, MySQL and other useful tools on all established

Documentation/10-Outlook/1-Creating-an-extension-with-the-kickstarter.rst

@@ -26,7 +26,7 @@ Concept
 -------
 
 The modelling of the domain model of an extension is the core functionality of the Extbase Kickstarter.
-In a graphical user interface the new domian objects are created, with performing properties
+In a graphical user interface the new domain objects are created, with performing properties
 and methods and applying the relations between the domain objects.
 
 During this phase of development the focus lies on the functionality of the domain model, and the
@@ -47,8 +47,8 @@ the templates to disk and can be used as a base for manual customizing.
 Sample modelling
 ----------------
 
-We want to demponstrate the usage of the kickstarter with an example of a little news extension.
-First we create a domian object ``News``, with the properties ``title``, ``author`` and ``text``.
+We want to demonstrate the usage of the kickstarter with an example of a little news extension.
+First we create a domain object ``News``, with the properties ``title``, ``author`` and ``text``.
 Because we additionally want to create a comment function for news, the domain objects needs a
 list of ``Comment`` objects in which the comments are to be stored.
 
@@ -59,7 +59,7 @@ is shown, with it you can model the domain objects.
 .. figure:: /Images/10-Outlook/figure-10-1.png
 
    Figure 10-1: The domain modeller consists of a large workspace and retractable tabs at the
-   left and right side, in wich the meta data can be entered.
+   left and right side, in which the meta data can be entered.
 
 To create a new domain object click at the box with the title *New Model Object* and pull it to
 the desired place on the workspace. Now you can enter the name of the model object, in our case
@@ -89,15 +89,15 @@ open the tab on the left side of the workspace and fill in the needed informatio
 click on *Save* the extension is saved and all files are generated.
 
 The extension can be installed with the extension manager now, and can be added to a page
-in the TYPO3 frontend. If you call this page, you will see that automagically a list, a single
+in the TYPO3 frontend. If you call this page, you will see that automatically a list, a single
 and a edit view for editing of news entries are generated - this is the dynamic Scaffolding.
 To change this to explicit templates the sub module *Convert Dynamic to Static Scaffolding*
 can be used.
 
-Now you have implementd a simple extension with the kickstarter and can further enhance it.
+Now you have implemented a simple extension with the kickstarter and can further enhance it.
 
 The extbase kickstarter resides - like said at the beginning - heavy in the development stage.
-At the moment there are plans of the development team to use a standarized description language
+At the moment there are plans of the development team to use a standardized description language
 for the emerging models. Also the team around the kickstarter will try to implement functions
 to edit existing extensions.
 

Documentation/10-Outlook/2-Backend-modules.rst

@@ -47,12 +47,12 @@ In line 12 till 16 common definitions for the access rights, the icon and the ti
 
 Now the backend module is ready equipped. You can try it out after installing the extension.
 Now you perhaps discover that the design has not the look and feel of a TYPO3 backend. To simplify the
-creation of aligned backend modules there are backend ViewHelper for ajustment of the design, that
+creation of aligned backend modules there are backend ViewHelper for adjustment of the design, that
 you will find below ``f:be.*``. Because these ViewHelper are heavy in enhancement, their documentation
 is not covered in this book. We approve instead to look at the templates of the current blog example.
 There you will find the recommended ViewHelper in action.
 
-Sometimes it is reasonable to configure the extension different in the fontend and backend. So it is
+Sometimes it is reasonable to configure the extension different in the frontend and backend. So it is
 necessary for the blog example to use different templates in frontend and backend.
 
 Backend modules can, like frontend plugins, be configured via TypoScript. While the frontend plugins
@@ -72,6 +72,6 @@ changed like this::
     }
 
 Here are all the settings of ``settings`` and ``persistence`` are copied from the configuration
-of the frontend plugins, only the new pathes for the ``view`` are set.
+of the frontend plugins, only the new paths for the ``view`` are set.
 
 Now you have a good oversight how you can use Extbase also for development of backend modules.

Documentation/2-BasicPrinciples/1-Object-oriented Programming-in-PHP.rst

@@ -146,7 +146,7 @@ Property is marked with the key word :php:`public` further down.
 We can also switch on the engine
 (:php:`startEngine()`), travel with the ship to the
 desired destination (:php:`moveTo($location)`) and switch
-off the engine again (:php:`stopEnginge()`). Note that all
+off the engine again (:php:`stopEngine()`). Note that all
 Methods are empty, i.e. we have no content at all. We'll change this in
 the following examples, of course. The line containing the Method name and (if
 available) parameters is called the Method signature or method head. Everything

Documentation/2-BasicPrinciples/2-Domain-Driven-Design.rst

@@ -206,7 +206,7 @@ value. You can only create a new value object and eliminate the old.
    these changed values. It must not change the existing object.
 
 By this simple semantics value objects can easily generated, cloned, transmitted
-to other computers or transfered to other objects. This not only the
+to other computers or transferred to other objects. This not only the
 implementation is easier, but it is also clearly communicated that these objects
 are just simple values​​.
 

Documentation/2-BasicPrinciples/4-Test-Driven-Development.rst

@@ -5,7 +5,7 @@ Test-Driven Development
 
 Every Developer has to test his software - for developers a not much liked
 theme, but one you cannot walk by. How work tests in the classic software
-development? Programmers in the first way construct a testcase by putting
+development? Programmers in the first way construct a test case by putting
 certain data into the database, write little programs to test or manipulate the
 url parameter in the browser. A big number of little functions are often
 implemented at one time, before they are tested (look at figure  2-7). After
@@ -20,7 +20,7 @@ more complex routine.
    :align: center
 
    Figure 2-7: in the classic software development exist a strict isolation
-   between the Development- and the Testphase.
+   between the Development- and the Test- phase.
 
 By using Test-Driven Development (TDD) these problems should be solved. Tests
 could be fast completed and reproducible. These increases the developers
@@ -49,7 +49,7 @@ callback, if a failure is implemented into the existing functions.
    seriously would have took me days until all would have worked at the end.
    Especially the feedback I got at once, I really appreciate. You click on a
    button and after a few seconds you got your feedback.
-   After this I am infected, learned about Mock- and Stubobjects, and today I do
+   After this I am infected, learned about Mock- and Stub- objects, and today I do
    not want to miss it. (In this chapter you will get an introduction into these concepts.)
    If you want to learn TDD, you will jump in at the deep end, and to
    try it at the next project. Until the first Unit test is finished, it will take
@@ -64,7 +64,7 @@ repeatable. The workflow is different of the classic programming, separated into
 very small iterations.
 
 Using Test-Driven Development you write your Unit tests for your features before
-you write your features theirselves. Unit tests are automatically repeatable
+you write your features themselves. Unit tests are automatically repeatable
 tests of methods, classes and little program parts. Even during the writing of
 the tests, you should seriously think about the desired functionality. When you
 are running your tests, they naturally will fail, because the tested
@@ -107,26 +107,26 @@ clearly higher than in the conventional Programming.
 Example
 -------
 
-Let us assume we want to model an onlineshop for a customer. These owns a name,
-which is transfered in the constructor. Through these tests we want to make sure
+Let us assume we want to model an online shop for a customer. These owns a name,
+which is transferred in the constructor. Through these tests we want to make sure
 that the name is correctly saved into the object. At first you have to install
 the phpunit-Extension from the TYPO3 Extension Repository (TER), because we will
 run the tests with this. The next step is to go to our own extension and create
 a folder "Tests/Unit/" in the main folder of the extension, if it not exists.
 This will contain later all our unit tests. Our customer object which we have to
 create, will be situated in Classes/Domain/Model/Customer.php because it is part
-of our Domainmodel in our extension.
+of our domain model in our extension.
 
-Similarly we create the testclass in the file
-Tests/Unit/Domain/Model/CustomerTest.php. Now we create a minimal testcase with which we get used with PHPUnit.
+Similarly we create the test class in the file
+Tests/Unit/Domain/Model/CustomerTest.php. Now we create a minimal test case with which we get used with PHPUnit.
 
 //code
 
-All our testcases are named after the same namescheme like normal classes and
-they must be extended with \TYPO3\CMS\Core\Tests\BaseTestCase. One testclass
-can contain many testmethods. These have to be public and have to contain the
+All our test cases are named after the same name scheme like normal classes and
+they must be extended with \TYPO3\CMS\Core\Tests\BaseTestCase. One test class
+can contain many test methods. These have to be public and have to contain the
 annotation @test in their PHPDOC-Block, so they can be performed. Please keep
-in mind that the name of the testmethod should make clear which expectations
+in mind that the name of the test method should make clear which expectations
 the test should fulfill. Now we can run the test for the first time. Therefore
 go to the TYPO3-Backend to the module PHPUnit which is to find under the Admin
 Tools. Then you can choose your extension and click on Run all tests. Now you
@@ -137,8 +137,8 @@ for extbase and fluid and also try the different Display options. For example
 you can let show you all tests or only the failed tests.
 
 
-Now we know that our testcase is running, we can write our first useful
-testcase. This should test, if a name which is specified in the constructor, can
+Now we know that our test case is running, we can write our first useful
+test case. This should test, if a name which is specified in the constructor, can
 be accessed again.
 
 //Code
@@ -149,10 +149,10 @@ be accessed again.
 .. figure:: /Images/2-BasicPrinciples/figure-2-9.png
    :align: center
 
-   Figure 2-9: With the testrunner you are able to run easily the Unit tests
+   Figure 2-9: With the test runner you are able to run easily the Unit tests
    in the TYPO3-Backend.
 
-When we run the testcase, we will be displayed a fatal error from PHP, because
+When we run the test case, we will be displayed a fatal error from PHP, because
 the class we want to test does not exist already. Now we are changing roles: We
 are not the user of the class anymore, but now we are the developer, who should
 implement the class. At first we create in the file
@@ -162,7 +162,7 @@ rid of the fatal error:
 //code
 
 
-When we now let run the testsuite again there should not be a fatal error
+When we now let run the test suite again there should not be a fatal error
 anymore but instead our Unit-Tests will fail because the getName() method returns
 the false value.
 Now we are able, motivated by getting the red bar fast as possible into green,
@@ -204,7 +204,7 @@ the figure 2-10: The email logger class has a reference on the email service.
 
 We now want to test the class EmailLogger without using the EmailService. We do
 not want to send real emails with every test run. To reach that goal we need two
-subelements. Dependency Injection and the use of Mock objects. Both concepts we
+sub elements. Dependency Injection and the use of Mock objects. Both concepts we
 will introduce below.
 
 Dependency Injection
@@ -271,7 +271,7 @@ In line 10 passes through the truly fascinating: We expect that in the
 EmailService an unique method call is sent, with the parameters
 :php:`'logging@domain.local','Message Log', $message`. Once we have specified our
 expectations, we can at line 11 let the EmailLogger log the message. At the end
-of the testcases our expectations are automatically controlled.
+of the test cases our expectations are automatically controlled.
 
 If the the method send was called exactly once or with the false parameter
 values, the test will fail with a detailed error message. What have we achieved?

Documentation/3-BlogExample/12-automatic-persistence-of-the-domain-logic.rst

@@ -40,7 +40,7 @@ the following order:
    this chapter. The persistence backend is a layer "above" the storage
    backend. It is responsible for the cycle of the persistence (what should
    be stored, deleted or changed in which order?), while the storage backend
-   has the job to translate the abstact requests into the native language of
+   has the job to translate the abstract requests into the native language of
    the "physical" storage option (most the SQL dialect of a database).
 
 In our case the persistence backend (in the following called backend)
@@ -58,7 +58,7 @@ property values.
    defined class of extbase. For the blog class this is
    ``\TYPO3\CMS\Extbase\DomainObject\AbstractEntity``. Inside this parent
    class a property ``$_cleanProperties`` is defined. This property
-   is directly, after the recontruction of the object (restored from the
+   is directly, after the reconstruction of the object (restored from the
    database), initialized with the unchanged property values with a call of
    ``_memorizeCleanState()``; in our case with the title, the
    description, the administrator and all ``post`` objects. With
@@ -70,7 +70,7 @@ property values.
    All methods that starts with an underline (_) are internal methods.
    These methods can be called from "outside" *(public)* in a technical view,
    but they should not called inside an extension - even though it is
-   attractive to do that. In FLOW3 the "observation" of the objects is solced
+   attractive to do that. In FLOW3 the "observation" of the objects is solved
    in an other way and it is not applicable to enhance a parent class of the
    framework. The declaration ``extends
    \TYPO3\CMS\Extbase\DomainObject\AbstractEntity`` can simply be removed when

Documentation/3-BlogExample/4-and-action.rst

@@ -74,11 +74,11 @@ change of an existing blog. The job of the
 
 .. tip::
 
-    Who already dealed with the model-view-controller-pattern will
+    Who already dealt with the model-view-controller-pattern will
     notice, that the controller has only a little amount of code. Extbase (and
     FLOW3) aim to the approach to have a slim controller. The controller is
     exclusively responsible for the control of the process flow. Additional
-    logic (especially business or domain logic) needs to be seperated into
+    logic (especially business or domain logic) needs to be separated into
     classes in the subfolder :file:`Domain`.
 
 .. tip::
@@ -109,7 +109,7 @@ At first call of the plugin without additional information the request
 will get a standard action; in our case the
 `indexAction()`. The
 `indexAction()` contains only one line in our example
-(as shown above), which looks more detailled like this::
+(as shown above), which looks more detailed like this::
 
     public function indexAction()
     {

Documentation/3-BlogExample/9-Rendering-the-output-with-fluid.rst

@@ -81,7 +81,7 @@ represent different functionalities.
 * `<f:link.action action="new">` creates a link tag that links to the :php:`newAction()` of the actual controller.
 * `<f:for each="{blogs}" as="blog">[...]</f:for>` iterates over all Blog-objects found in Blogs.
 
-Let's have a closer look at the latter examaple. In the variable `{blogs}` all
+Let's have a closer look at the latter example. In the variable `{blogs}` all
 blogs are "included". The curly brackets tell Fluid that it is a variable that
 was "assigned" to the template before. In our case this was done in the
 :php:`indexAction()` of the `BlogController`. With the attribute `each` the

Documentation/3-BlogExample/Index.rst

@@ -13,7 +13,7 @@ A journey through the Blog Example
      `plobacher/extbasebookexamplev8 <https://github.com/plobacher/extbasebookexamplev8>`__,
      see the `Extbase book <https://leanpub.com/typo3extbase-en>`__ ,
      `Extbase book in German <https://leanpub.com/typo3extbase>`__ or
-     `Extbase book in Italien <https://leanpub.com/typo3extbase-it>`__.
+     `Extbase book in Italian <https://leanpub.com/typo3extbase-it>`__.
 
 In this chapter we accompany you on a journey through a simple TYPO3 extension.
 While travelling on this round trip, you will get to know more about extension

Documentation/4-FirstExtension/3-create-the-domain-model.rst

@@ -21,7 +21,7 @@ This class file is stored in the folder :file:`EXT:store_inventory/Classes/Domai
     Pay attention to the corresponding upper case of the folder names.
 
 Below we have a view into this file, note that the class
-:php:`\MyVendor\StoreInventory\Domain\Model\Product` must be derivated
+:php:`\MyVendor\StoreInventory\Domain\Model\Product` must be derived
 from the extbase class
 :php:`\TYPO3\CMS\Extbase\DomainObject\AbstractEntity`.
 

Documentation/4-FirstExtension/7-configuring-the-plugin.rst

@@ -36,7 +36,7 @@ follows from the name of the extension directory) prefixed by the vendor
 namespace followed by a dot. This indicates, that we use namespaces for our php
 classes.  With the second argument we give an unique name for the plugin (in
 UpperCamelCase notation).  Because of historical reasons there is often used
-``Pi1``, but maybe it is better to use more meaningfull names like
+``Pi1``, but maybe it is better to use more meaningful names like
 "InventoryList".
 This is used later to clearly identify the plugin amongst other plugins on the page.
 The third argument is an array with all controller action combinations, the plugin