Merge pull request #466 from maastermedia/master

Typos in documentation

README.md

@@ -134,7 +134,7 @@ Features
     - Contextual Breadcrumb
     - persistent parameters across an Admin
     - side menu option
-    - Translated into 14 languages : CA, DE, EN, ES, FR, IT, JA, NL, PL, PT_BR, PT_PT, RU, UK an HR.
+    - Translated into 16 languages : CA, DE, EN, ES, FR, HR, IT, JA, LB, NL, PL, PT_BR, PT_PT, RU, SL and UK.
     - Built to be extended
     - Explain command line utility
 

Resources/doc/reference/advance.rst

@@ -4,7 +4,7 @@ Advance
 Service Configuration
 ---------------------
 
-When you create a new Admin service you can configure its dependencies, by default services who are injected are:
+When you create a new Admin service you can configure its dependencies, by default services which are injected are:
 
 ========================      =============================================
 Dependencies                  Service Id
@@ -24,7 +24,7 @@ router_builder                sonata.admin.route.path_info
 label_translator_strategy     sonata.admin.label.strategy.form_component
 =========================     =============================================
 
-Note: %manager-type% is replace by the manager type (orm, odm...)
+Note: %manager-type% is replaced by the manager type (orm, odm...)
 
 You have 2 ways of defining the dependencies inside a ``services.xml``.
 
@@ -71,7 +71,7 @@ You have 2 ways of defining the dependencies inside a ``services.xml``.
         </service>
 
 
-If you want to modify the service who are going to be injected, add the following code to your
+If you want to modify the service which is going to be injected, add the following code to your
 application's config file:
 
 .. code-block:: yaml

Resources/doc/reference/architecture.rst

@@ -1,7 +1,7 @@
 Architecture
 ============
 
-The architecture of the bundle is primarily inspired by the Django Admin
+The architecture of the SonataAdminBundle is primarily inspired by the Django Admin
 Project, which is truly a great project. More information can be found at the
 `Django Project Website`_.
 
@@ -70,14 +70,14 @@ The definition contains:
 * ``options``: Certain field types have additional options;
 
 Template Configuration
------------------------
+----------------------
 
 The current implementation uses Twig as the template engine. All templates
 are located in the ``Resources/views/CRUD`` directory of the bundle. The base
 template extends two layouts:
 
-* ``AdminBundle::standard_layout.twig``
-* ``AdminBundle::ajax_layout.twig``
+* ``AdminBundle::standard_layout.html.twig``
+* ``AdminBundle::ajax_layout.html.twig``
 
 The base templates can be configured in the Service Container. So you can easily tweak
 the layout to suit your requirements.
@@ -89,10 +89,10 @@ templates will be used:
 * ``filter_text.twig``: template used in the filter box
 * ``list_text.twig``: template used in the list table
 
-CrudController
+CRUDController
 --------------
 
-The controller contains the basic CRUD actions, it controller is related to one
+The controller contains the basic CRUD actions. It is related to one
 ``Admin`` class by mapping the controller name to the correct ``Admin``
 instance.
 
@@ -106,8 +106,8 @@ Obtaining an ``Admin`` Service
 ------------------------------
 
 ``Admin`` definitions are accessible through the 'sonata.admin.pool' service or
-directly from the DIC. The ``Admin`` definitions are lazy loaded from the DIC to
-reduce overhead.
+directly from the DIC (dependency injector). The ``Admin`` definitions are lazy
+loaded from the DIC to reduce overhead.
 
 Declaring a new Admin class
 ---------------------------

Resources/doc/reference/conditional_validation.rst

@@ -3,12 +3,12 @@ Inline Validation
 
 The inline validation is about delegating model validation to a dedicated service.
 The current validation implementation built in the Symfony2 framework is very powerful
-as it allows to declare validation on : class, field and getter. However these declaration
-can take a while to code for complexe rules. As a rules must be a set of a ``Constraint``
-and ``Validator`` instance.
+as it allows to declare validation on : class, field and getter. However these declarations
+can take a while to code for complex rules. Rules must be a set of a ``Constraint``
+and ``Validator`` instances.
 
-The inline validation try to provide a nice solution by introducting a ``ErrorElement``
-object. The object can be use to check assertion against a model :
+The inline validation tries to provide a nice solution by introducting an ``ErrorElement``
+object. The object can be used to check assertion against the model :
 
 .. code-block:: php
 
@@ -40,7 +40,7 @@ object. The object can be use to check assertion against a model :
 
 .. note::
 
-    This solution rely on the validator component so validation defined through
+    This solution relies on the validator component so validation defined through
     the validator component will be used.
 
 Using this validator

Resources/doc/reference/configuration.rst

@@ -10,7 +10,7 @@ Configuration options
 * ``title`` : The admin's title, can be the client name for instance (default: Sonata Admin)
 * ``title_logo`` : logo to use, must be an image with a height of 28px (default : /bundles/sonataadmin/logo_title.png)
 
-Please see :ref:`templates` for more information about how to configure default templates.
+Please see :ref:`templates` for more information on how to configure default templates.
 
 
 Full Configuration Options
@@ -28,7 +28,7 @@ Full Configuration Options
             layout:  SonataAdminBundle::standard_layout.html.twig
             ajax:    SonataAdminBundle::ajax_layout.html.twig
 
-            # default value if done set, actions templates, should extends a global templates
+            # default actions templates, should extends a global templates
             list:    SonataAdminBundle:CRUD:list.html.twig
             show:    SonataAdminBundle:CRUD:show.html.twig
             edit:    SonataAdminBundle:CRUD:edit.html.twig

Resources/doc/reference/dashboard.rst

@@ -11,7 +11,7 @@ application's config file:
     # app/config/config.yml
     sonata_admin:
         dashboard_groups:
-    ... your config ...
+            ... your config ...
 
 
 Examples
@@ -51,7 +51,7 @@ Add a group with all the default items
         dashboard_groups:
             sonata_page: ~
 
-Add some items in a group
+Add some items to a group
 ^^^^^^^^^^^^^^^^^^^^^^^^^
 
 .. code-block:: yaml

Resources/doc/reference/field_types.rst

@@ -7,7 +7,7 @@ List and Show Actions
 There are many field types that can be used in the list action or show action :
 
 * array: display value from an array
-* boolean: display a green or red picture depend on the boolean value, this type accepts an ``editable``
+* boolean: display a green or red picture dependant on the boolean value, this type accepts an ``editable``
   parameter to edit the value from within the list or the show actions
 * date: display a formatted date
 * datetime: display a formatted date
@@ -24,5 +24,5 @@ There are many field types that can be used in the list action or show action :
     will be changed to use localized information.
 
 
-More types might be provided depends on the persistency layer defined. Please refer to there
+More types might be provided based on the persistency layer defined. Please refer to their
 related documentations.

Resources/doc/reference/form_types.rst

@@ -15,14 +15,14 @@ The bundle comes with some handy form types which are available from outside the
 sonata_type_immutable_array
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-The ``Immutable Array`` allows to edit an array property by defining a type per key.
+The ``Immutable Array`` allows you to edit an array property by defining a type per key.
 
 The type has a ``keys`` parameter which contains the definition for each key. A definition is an array with 3 options :
-* the key name
-* the type : a type name or the a ``FormType`` instance
-* the related type parameters : please refer to the related form documentation.
+* key name
+* type : a type name or a ``FormType`` instance
+* related type parameters : please refer to the related form documentation.
 
-Let's say a ``Page`` have a options property with some fixed key-pair values, each value has a type different : integer,
+Let's say a ``Page`` have options property with some fixed key-pair values, each value has a different type : integer,
 url, or string for instance.
 
 .. code-block:: php

Resources/doc/reference/installation.rst

@@ -83,7 +83,7 @@ At this point you can access to the dashboard with the url:
     the above configuration and routing will actually be placed in those
     files, with the correct format (i.e. XML or PHP).
 
-The last important step is security, please refer to the dedicated section.
+The last important step is security, please refer to the dedicated section of this documentation.
 
 Users management
 ----------------
@@ -99,7 +99,7 @@ The ``SonataUserBundle`` is just a thin wrapper to include the ``FOSUserBundle``
 
 * A default login area
 * A default ``user_block`` template which is used to display the current user and the logout link
-* 2 Admin class : User and Group
+* 2 Admin classes : User and Group
 * A default class for User and Group.
 
 There is a little magic in the ``SonataAdminBundle`` if the bundle detects the ``SonataUserBundle`` class, then

Resources/doc/reference/routing.rst

@@ -69,8 +69,8 @@ defined by its name.
 Persistent parameters
 ---------------------
 
-In some cases, the interface might required to pass the same parameters across the different ``Admin``'s actions.
-Instead of settings them in the template or doing other weird hacks, you can defined a ``getPersistentParameters``
+In some cases, the interface might be required to pass the same parameters across the different ``Admin``'s actions.
+Instead of setting them in the template or doing other weird hacks, you can define a ``getPersistentParameters``
 method. This method will be used when a link is being generated.
 
 .. code-block:: php

Resources/doc/reference/saving_hooks.rst

@@ -1,11 +1,11 @@
 Saving hooks
 ============
 
-When the model is persited upon on the object stated two Admin methods are always call. You can extends this
+When the model is persited upon on the object stated two Admin methods are always called. You can extend this
 method to add custom business logic.
 
     - new object : ``prePersist($object)`` / ``postPersist($object)``
-    - new object : ``preUpdate($object)`` / ``postUpdate($object)``
+    - edited object : ``preUpdate($object)`` / ``postUpdate($object)``
     - deleted object : ``preRemove($object)`` / ``postRemove($object)``
 
 

Resources/doc/reference/security.rst

@@ -4,7 +4,7 @@ Security
 The security part is managed by a ``SecurityHandler``, the bundle comes with 2 handlers
 
   - ``sonata.admin.security.handler.acl`` : ACL and ROLES to handle permissions
-  - ``sonata.admin.security.handler.noop`` : always return true, can be used with the Symfony2 firewall
+  - ``sonata.admin.security.handler.noop`` : always returns true, can be used with the Symfony2 firewall
 
 The default value is ``sonata.admin.security.handler.noop``, if you want to change the default value
 you can set the ``security_handler`` to ``sonata.admin.security.handler.acl``.
@@ -22,11 +22,11 @@ ACL and FriendsOfSymfony/UserBundle
 
 If you want an easy way to handle users, please use :
 
- - https://github.com/FriendsOfSymfony/FOSUserBundle : handle users and group stored from RDMS or MongoDB
- - https://github.com/sonata-project/SonataUserBundle : integrate the ``FriendsOfSymfony/UserBundle`` with
+ - https://github.com/FriendsOfSymfony/FOSUserBundle : handle users and groups stored in RDMS or MongoDB
+ - https://github.com/sonata-project/SonataUserBundle : integrates the ``FriendsOfSymfony/UserBundle`` with
    the ``AdminBundle``
 
-The security integration is a work in progress and have some knows issues :
+The security integration is a work in progress and has some known issues :
  - ACL permissions are immutables
  - Only one PermissionMap can be defined
 
@@ -80,7 +80,7 @@ The following configuration for the SonataUserBundle defines:
     - the ``FriendsOfSymfony/FOSUserBundle`` as a security provider
     - the login form for authentification
     - the access control : resources with related required roles, the important part is the admin configuration
-    - the ``acl`` option enable the ACL.
+    - the ``acl`` option to enable the ACL.
 
 In ``app/config/config.yml``:
 
@@ -172,10 +172,10 @@ If you have Admin classes, you can install the related CRUD ACL rules :
        - add role: ROLE_SONATA_MEDIA_ADMIN_MEDIA_OPERATOR, ACL: ["OPERATOR"]
     ... skipped ...
 
-If you try to access to the admin class you should see the login form, just logon with the ``root`` user.
+If you try to access the admin class you should see the login form, just logon with the ``root`` user.
 
 Usage
 ~~~~~
 
-Everytime you create a new ``Admin`` class, you should create start the command ``php app/console sonata:admin:setup-acl``
+Everytime you create a new ``Admin`` class, you should create ACL by using the command ``php app/console sonata:admin:setup-acl``
 so the ACL database will be updated with the latest masks and roles informations.

Resources/doc/reference/templates.rst

@@ -1,7 +1,7 @@
 Templates
 =========
 
-By default, an Admin class used a set of templates, it is possible to tweak the default values by editing the configuration
+By default, an Admin class use a set of templates, it is possible to tweak the default values by editing the configuration
 
 .. code-block:: yaml
 
@@ -20,7 +20,7 @@ By default, an Admin class used a set of templates, it is possible to tweak the
 
 Usage of each template :
 
-* layout : based layout used by the dashboard and an admin class
+* layout : base layout used by the dashboard and an admin class
 * ajax : default layout used when an ajax request is performed
 * list : the template to use for the list action
 * show : the template to use for the show action

Resources/doc/reference/translation.rst

@@ -3,8 +3,8 @@ Translation
 
 There are two main catalogue names in an Admin class:
 
-* ``SonataAdminBundle`` : this catalogue is used to translate shared messages accross different admin
-* ``messages`` : this catalogue is used to translate the message for the current admin
+* ``SonataAdminBundle`` : this catalogue is used to translate shared messages accross different admins
+* ``messages`` : this catalogue is used to translate the messages for the current admin
 
 Ideally the ``messages`` catalogue should be changed to avoid any issues with other Admin classes.
 
@@ -37,7 +37,7 @@ You have two options to configure the catalogue for the admin class:
         </service>
 
 
-An admin instance always get the ``translator`` instance, so it can be used to translate messages within the
+An admin instance always gets the ``translator`` instance, so it can be used to translate messages within the
 ``configure*Fields`` method or in templates.
 
 .. code-block:: jinja
@@ -60,7 +60,7 @@ Translate field labels
 The Admin bundle comes with a customized form field template. The most notable changes from the original one is the use
 of the translation domain provided by the Admin instance to translate label.
 
-By default, the label is the the field name. However a label can be defined as a the third argument of the ``add`` method:
+By default, the label is the field name. However a label can be defined as a the third argument of the ``add`` method:
 
 .. code-block:: php
 
@@ -84,15 +84,15 @@ fields: ``Label Strategies``. By default labels are generated by using by using
 
 The ``AdminBundle`` comes with different key label generation strategies:
 
-* ``sonata.admin.label.strategy.native`` : DEFAULT - Make the string human readable readable - ``isValid`` => ``Is Valid``
+* ``sonata.admin.label.strategy.native`` : DEFAULT - Makes the string human readable readable - ``isValid`` => ``Is Valid``
 * ``sonata.admin.label.strategy.form_component`` : The default behavior from the Form Component - ``isValid`` => ``Isvalid``)
-* ``sonata.admin.label.strategy.underscore`` : Add undescore to the label  - ``isValid`` => ``form.label_is_valid``
+* ``sonata.admin.label.strategy.underscore`` : Adds undescore to the label  - ``isValid`` => ``form.label_is_valid``
 * ``sonata.admin.label.strategy.noop`` : does not alter the string - ``isValid`` => ``isValid``
-* ``sonata.admin.label.strategy.bc`` : preserve the old label generation from the early version of ``SonataAdminBundle``
+* ``sonata.admin.label.strategy.bc`` : preserves the old label generation from the early version of ``SonataAdminBundle``
 
 ``sonata.admin.label.strategy.underscore`` will be better for i18n applications and ``sonata.admin.label.strategy.native`
 will be better for native language based on the field name. So it is possible to start with the ``native`` strategy and then
-when the application need to be translated using generic keys the configuration can be switched to used the ``sonata.admin.label.strategy.underscore``.
+when the application needs to be translated using generic keys the configuration can be switched to the ``sonata.admin.label.strategy.underscore``.
 
 The strategy can be quickly configured when the Admin class is registered into the Container:
 
@@ -113,8 +113,8 @@ The strategy can be quickly configured when the Admin class is registered into t
 
 .. note::
 
-    In all cases the label will be used by the ``Translator``. The strategy is just a quick way to generate translable keys
-    depends on the project's requirements.
+    In all cases the label will be used by the ``Translator``. The strategy is just a quick way to generate translable keys.
+    It all depends on the project's requirements.
 
 
 .. note::