fixed typos

manual/en/annotations-reference.txt

@@ -50,9 +50,9 @@ Optional attributes:
 * length - Used by the "string" type to determine its maximum length in the database. Doctrine does not validate the length of a string values for you.
 * precision - The precision for a decimal (exact numeric) column (Applies only for decimal column)
 * scale - The scale for a decimal (exact numeric) column (Applies only for decimal column)
-* unique - Boolean value to determine if the value of the column should be unique accross all rows of the underlying entities table.
+* unique - Boolean value to determine if the value of the column should be unique across all rows of the underlying entities table.
 * nullable - Determines if NULL values allowed for this column.
-* columnDefinition - DDL SQL snippet that starts after the column name and specificies the complete (non-portable!) column definition. This attribute allows to make use of advanced RMDBS features. However you should make careful use of this feature and the consequences. Additionally you should remember that the "type" attribute still handles the conversion between PHP and Database values. If you use this attribute on a column that is used for joins between tables you should also take a look at [@JoinColumn](#ann_joincolumn).
+* columnDefinition - DDL SQL snippet that starts after the column name and specifies the complete (non-portable!) column definition. This attribute allows to make use of advanced RMDBS features. However you should make careful use of this feature and the consequences. Additionally you should remember that the "type" attribute still handles the conversion between PHP and Database values. If you use this attribute on a column that is used for joins between tables you should also take a look at [@JoinColumn](#ann_joincolumn).
 
 Examples:
 
@@ -76,7 +76,7 @@ Examples:
 +++ @ChangeTrackingPolicy
 
 The Change Tracking Policy annotation allows to specify how the Doctrine 2 UnitOfWork should detect changes
-in properties of entities during flush. By default each entity is checked according to a deferred implict
+in properties of entities during flush. By default each entity is checked according to a deferred implicit
 strategy, which means upon flush UnitOfWork compares all the properties of an entity to a previously stored
 snapshot. This works out of the box, however you might want to tweak the flush performance where using
 another change tracking policy is an interesting option.
@@ -98,7 +98,7 @@ Example:
 <a name="ann_discriminatorcolumn"></a>
 +++ @DiscrimnatorColumn
 
-This annotation is a required annotation for the topmost/super class of an inheritance hierachy. It specifies
+This annotation is a required annotation for the topmost/super class of an inheritance hierarchy. It specifies
 the details of the column which saves the name of the class, which the entity is actually instantiated as.
 
 Required attributes:
@@ -113,7 +113,7 @@ Optional attributes:
 <a name="ann_discriminatormap"></a>
 +++ @DiscriminatorMap
 
-The discrimnator map is a required annotation on the top-most/super class in an inheritance hierachy. It takes
+The discriminator map is a required annotation on the top-most/super class in an inheritance hierarchy. It takes
 an array as only argument which defines which class should be saved under which name in the database. Keys
 are the database value and values are the classes, either as fully- or as unqualified class names depending
 if the classes are in the namespace or not.
@@ -138,7 +138,7 @@ Required annotation to mark a PHP class as Entity. Doctrine manages the persiste
 
 Optional attributes:
 
-* repositoryClass - Specifies the FQCN of a subclass of the Doctrine\ORM\EntityRepository. Use of repositories for entites is encouraged to keep specialized DQL and SQL operations separated from the Model/Domain Layer.
+* repositoryClass - Specifies the FQCN of a subclass of the Doctrine\ORM\EntityRepository. Use of repositories for entities is encouraged to keep specialized DQL and SQL operations separated from the Model/Domain Layer.
 
 Example:
 
@@ -222,7 +222,7 @@ Example:
 +++ @Id
 
 The annotated instance variable will be marked as entity identifier, the primary key in the database.
-This annotation is a marker only and has no required or optional attributes. For entites that have multiple
+This annotation is a marker only and has no required or optional attributes. For entities that have multiple
 identifier columns each column has to be marked with @Id.
 
 Example:
@@ -237,7 +237,7 @@ Example:
 <a name="ann_inheritancetype"></a>
 +++ @InheritanceType
 
-In an inheritance hierachy you have to use this annotation on the topmost/super class to define which
+In an inheritance hierarchy you have to use this annotation on the topmost/super class to define which
 strategy should be used for inheritance. Currently Single Table and Class Table Inheritance are supported.
 
 This annotation has always been used in conjunction with the [@DiscriminatorMap](#ann_discriminatormap) and
@@ -273,7 +273,7 @@ Examples:
 
 This annotation is used in the context of relations in [@ManyToOne](#ann_manytoone), [@OneToOne](#ann_onetoone) fields
 and in the Context of [@JoinTable](#ann_jointable) nested inside a @ManyToMany. This annotation is not required.
-If its not specified the attributes *name* and *referencedColumnName* are infered from the table and primary key names.
+If its not specified the attributes *name* and *referencedColumnName* are inferred from the table and primary key names.
 
 Required attributes:
 
@@ -286,7 +286,7 @@ Optional attributes:
 * nullable - Determine if the related entity is required, or if null is an allowed state for the relation. Defaults to true.
 * onDelete - Cascade Action (Database-level)
 * onUpdate - Cascade Action (Database-level)
-* columnDefinition - DDL SQL snippet that starts after the column name and specificies the complete (non-portable!) column definition. This attribute allows to make use of advanced RMDBS features. Using this attribute on @JoinColumn is necessary if you need slightly different column definitions for joining columns, for example regarding NULL/NOT NULL defaults. However by default a "columnDefinition" attribute on [@Column](#ann_column) also sets the related @JoinColumn's columnDefinition. This is necessary to make foreign keys work.
+* columnDefinition - DDL SQL snippet that starts after the column name and specifies the complete (non-portable!) column definition. This attribute allows to make use of advanced RMDBS features. Using this attribute on @JoinColumn is necessary if you need slightly different column definitions for joining columns, for example regarding NULL/NOT NULL defaults. However by default a "columnDefinition" attribute on [@Column](#ann_column) also sets the related @JoinColumn's columnDefinition. This is necessary to make foreign keys work.
 
 Example:
 
@@ -306,14 +306,14 @@ with an entity that has multiple identifiers.
 <a name="ann_jointable"></a>
 +++ @JoinTable
 
-Using [@OneToMany](#ann_onetomany) or [@ManyToMany](#ann_manytomany) on the owning side of the relation requires to specifiy
+Using [@OneToMany](#ann_onetomany) or [@ManyToMany](#ann_manytomany) on the owning side of the relation requires to specify
 the @JoinTable annotation which describes the details of the database join table. If you do not specify @JoinTable on
 these relations reasonable mapping defaults apply using the affected table and the column names.
 
 Required attributes:
 
 * name - Database name of the join-table
-* joinColumns - An array of @JoinColumn annotations describing the join-relation between the owning entites table and the join table.
+* joinColumns - An array of @JoinColumn annotations describing the join-relation between the owning entities table and the join table.
 * inverseJoinColumns - An array of @JoinColumn annotations describing the join-relation between the inverse entities table and the join table.
 
 Optional attributes:
@@ -345,7 +345,7 @@ Optional attributes:
 
 * cascade - Cascade Option
 * fetch - One of LAZY or EAGER
-* inversedBy - The inversedBy attribute designates the field in the entity that is the inverse side of the relationship.
+* inversedBy - The inversedBy attribute designates the field in the entity that is the inverse side of the relationship.
 
 Example:
 
@@ -521,7 +521,7 @@ Marks a method on the entity to be called as a @PreUpdate event. Only works with
 <a name="ann_sequencegenerator"></a>
 +++ @SequenceGenerator
 
-For the use with @generatedValue(strategy="SEQUENCE") this annotation allows to specifiy details about the sequence,
+For the use with @generatedValue(strategy="SEQUENCE") this annotation allows to specify details about the sequence,
 such as the increment size and initial values of the sequence.
 
 Required attributes:

manual/en/architecture.txt

@@ -54,7 +54,7 @@ entity instance still holds references to proxy objects or is still managed by a
 If you intend to serialize (and unserialize) entity instances that still hold references to proxy objects
 you may run into problems with private properties because of technical limitations.
 Proxy objects implement `__sleep` and it is not possible for `__sleep` to return names of
-private properties in parent classes. On ther other hand it is not a solution for proxy objects
+private properties in parent classes. On the other hand it is not a solution for proxy objects
 to implement `Serializable` because Serializable does not work well with any potential cyclic
 object references (at least we did not find a way yet, if you did, please contact us).
 

manual/en/association-mapping.txt

@@ -11,9 +11,9 @@ When mapping bidirectional associations it is important to understand the concep
 
 The following rules apply to *bidirectional* associations:
 
-* The inverse side of a bidirectional relationship must refer to its owning side by use of the mappedBy attribute of the OneToOne, OneToMany, or ManyToMany mapping declaration. The mappedBy attribute designates the field in the entity that is the owner of the relationship.
+* The inverse side of a bidirectional relationship must refer to its owning side by use of the mappedBy attribute of the OneToOne, OneToMany, or ManyToMany mapping declaration. The mappedBy attribute designates the field in the entity that is the owner of the relationship.
-* The owning side of a bidirectional relationship must refer to its inverse side by use of the inversedBy attribute of the OneToOne, ManyToOne, or ManyToMany mapping declaration. The inversedBy attribute designates the field in the entity that is the inverse side of the relationship.
+* The owning side of a bidirectional relationship must refer to its inverse side by use of the inversedBy attribute of the OneToOne, ManyToOne, or ManyToMany mapping declaration. The inversedBy attribute designates the field in the entity that is the inverse side of the relationship.
-* The many side of OneToMany/ManyToOne bidirectional relationships *must* be the owning side, hence the mappedBy element can not be specified on the ManyToOne side.
+* The many side of OneToMany/ManyToOne bidirectional relationships *must* be the owning side, hence the mappedBy element can not be specified on the ManyToOne side.
 * For OneToOne bidirectional relationships, the owning side corresponds to the side that contains the corresponding foreign key (@JoinColumn(s)).
 * For ManyToMany bidirectional relationships either side may be the owning side (the side that defines the @JoinTable and/or does not make use of the mappedBy attribute, thus using a default join table).
 
@@ -43,7 +43,7 @@ in the database.
 
 ++ Collections
 
-In all the examples of many-valued associations in this manual we will make use of a `Collection` interface and a corresponding default implementation `ArrayCollection` that are defined in the `Doctrine\Common\Collections` namespace. Why do we need that? Doesn't that couple my domain model to Doctrine? Unfortunately, PHP arrays, while being great for many things, do not make up for good collections of business objects, especially not in the context of an ORM. The reason is that plain PHP arrays can not be transparently extended / instrumented in PHP code, which is necessary for a lot of advanced ORM features. The classes / interfaces that come closest to an OO collection are ArrayAccess and ArrayObject but until instances of these types can be used in all places where a plain array can be used (something that may happen in PHP6) their useability is fairly limited. You "can" type-hint on `ArrayAccess` instead of `Collection`, since the Collection interface extends `ArrayAccess`, but this will severely limit you in the way you can work with the collection, because the `ArrayAccess` API is (intentionally) very primitive and more importantly because you can not pass this collection to all the useful PHP array functions, which makes it very hard to work with.
+In all the examples of many-valued associations in this manual we will make use of a `Collection` interface and a corresponding default implementation `ArrayCollection` that are defined in the `Doctrine\Common\Collections` namespace. Why do we need that? Doesn't that couple my domain model to Doctrine? Unfortunately, PHP arrays, while being great for many things, do not make up for good collections of business objects, especially not in the context of an ORM. The reason is that plain PHP arrays can not be transparently extended / instrumented in PHP code, which is necessary for a lot of advanced ORM features. The classes / interfaces that come closest to an OO collection are ArrayAccess and ArrayObject but until instances of these types can be used in all places where a plain array can be used (something that may happen in PHP6) their usability is fairly limited. You "can" type-hint on `ArrayAccess` instead of `Collection`, since the Collection interface extends `ArrayAccess`, but this will severely limit you in the way you can work with the collection, because the `ArrayAccess` API is (intentionally) very primitive and more importantly because you can not pass this collection to all the useful PHP array functions, which makes it very hard to work with.
 
 > **CAUTION**
 > The Collection interface and ArrayCollection class, like everything else in the
@@ -57,7 +57,7 @@ In all the examples of many-valued associations in this manual we will make use
 
 ++ Mapping Defaults
 
-Before we introduce all the association mappings in detailyou should note that the @JoinColumn and @JoinTable
+Before we introduce all the association mappings in detail, you should note that the @JoinColumn and @JoinTable
 definitions are usually optional and have sensible default values.
 The defaults for a join column in a one-to-one/many-to-one association is as follows:
 

manual/en/basic-mapping.txt

@@ -237,7 +237,7 @@ This tells Doctrine to automatically generate a value for the identifier. How th
 +++ Identifier Generation Strategies
 
 The previous example showed how to use the default identifier generation strategy without knowing the underlying database with the AUTO-detection strategy.
-It is also possible to specifiy the identifier generation strategy more explicitly, which allows to make use of some additional features.
+It is also possible to specify the identifier generation strategy more explicitly, which allows to make use of some additional features.
 
 Here is the list of possible generation strategies:
 
@@ -256,7 +256,7 @@ Here is the list of possible generation strategies:
 ++++ Sequence Generator
 
 The Sequence Generator can currently be used in conjunction with Oracle or Postgres and allows some additional configuration options besides
-specifiying the sequence's name:
+specifying the sequence's name:
 
     [php]
     class User {
@@ -292,7 +292,7 @@ Doctrine can generate identifier values for the allocationSizes amount of entiti
 
 +++ Composite Keys
 
-Doctrine 2 allows to use composite primary keys. There are however some restrictions oposed to using a single identifier.
+Doctrine 2 allows to use composite primary keys. There are however some restrictions opposed to using a single identifier.
 The use of the `@GeneratedValue` annotation is only supported for simple (not composite) primary keys, which means
 you can only use composite keys if you generate the primary key values yourself before calling `EntityManager#persist()`
 on the entity.

manual/en/best-practices.txt

@@ -72,6 +72,6 @@ Foreign keys have no meaning whatsoever in an object model. Foreign keys are how
 
 While Doctrine will automatically wrap all DML operations in a transaction on flush(), it is considered best practice to explicitly set the transaction boundaries yourself.
 Otherwise every single query is wrapped in a small transaction (Yes, SELECT queries, too) since you can not talk to your database outside of a transaction.
-While such short transactions for read-only (SELECT) queries generally dont have any noticable performance impact, it is still preferrable to use fewer, well-defined transactions
+While such short transactions for read-only (SELECT) queries generally don't have any noticeable performance impact, it is still preferable to use fewer, well-defined transactions
 that are established through explicit transaction boundaries.
 

manual/en/dql-doctrine-query-language.txt

@@ -273,7 +273,7 @@ Get all users that have no phonenumber
     $query = $em->createQuery('SELECT u FROM CmsUser u WHERE u.phonenumbers IS EMPTY');
     $users = $query->getResult();
 
-Get all instances of a specific type, for use with inheritance hierachies:
+Get all instances of a specific type, for use with inheritance hierarchies:
 
     [php]
     $query = $em->createQuery('SELECT u FROM Doctrine\Tests\Models\Company\CompanyPerson u WHERE u INSTANCE OF Doctrine\Tests\Models\Company\CompanyEmployee');
@@ -304,7 +304,7 @@ You use the partial syntax when joining as well:
 The INDEX BY construct is nothing that directly translates into SQL but that affects
 object and array hydration. After each FROM and JOIN clause you specify by which field
 this class should be indexed in the result. By default a result is incremented
-by numerical keys starting with 0. However with INDEX BY you can specifiy any
+by numerical keys starting with 0. However with INDEX BY you can specify any
 other column to be the key of your result, it really only makes sense with primary
 or unique fields though:
 
@@ -340,7 +340,7 @@ example shows:
 
     UPDATE MyProject\Model\User u SET u.password = 'new' WHERE u.id IN (1, 2, 3)
 
-References to related entities are only possible in the WHERE clause and using subselects.
+References to related entities are only possible in the WHERE clause and using sub-selects.
 
 > **CAUTION**
 > DQL UPDATE statements are ported directly into a Database UPDATE statement and therefore bypass
@@ -375,11 +375,11 @@ The following functions are supported in SELECT, WHERE and HAVING clauses:
 * CURRENT_TIME() - Returns the current time
 * CURRENT_TIMESTAMP() - Returns a timestamp of the current date and time.
 * LENGTH(str) - Returns the length of the given string
-* LOCATE(needle, haystack [, offset]) - Locate the first occurance of the substring in the string.
+* LOCATE(needle, haystack [, offset]) - Locate the first occurrence of the substring in the string.
 * LOWER(str) - returns the string lowercased.
 * MOD(a, b) - Return a MOD b.
 * SIZE(collection) - Return the number of elements in the specified collection
-* SQRT(q) - Return the squareroot of q.
+* SQRT(q) - Return the square-root of q.
 * SUBSTRING(str, start [, length]) - Return substring of given string.
 * TRIM([LEADING | TRAILING | BOTH] ['trchar' FROM] str) - Trim the string by the given trim char, defaults to whitespaces.
 * UPPER(str) - Return the upper-case of the given string.
@@ -399,12 +399,12 @@ The following aggregate functions are allowed in SELECT and GROUP BY clauses: AV
 DQL offers a wide-range of additional expressions that are known from SQL, here is a list of
 all the supported constructs:
 
-* `ALL/ANY/SOME` - Used in a WHERE clause followed by a subselect this works like the equivalent constructs in SQL.
+* `ALL/ANY/SOME` - Used in a WHERE clause followed by a sub-select this works like the equivalent constructs in SQL.
 * `BETWEEN a AND b` and `NOT BETWEEN a AND b` can be used to match ranges of arithmetic values.
 * `IN (x1, x2, ...)` and `NOT IN (x1, x2, ..)` can be used to match a set of given values.
 * `LIKE ..` and `NOT LIKE ..` match parts of a string or text using % as a wildcard.
 * `IS NULL` and `IS NOT NULL` to check for null values
-* `EXISTS` and `NOT EXISTS` in combination with a subselect
+* `EXISTS` and `NOT EXISTS` in combination with a sub-select
 
 +++ Adding your own functions to the DQL language
 
@@ -586,7 +586,7 @@ An instance of the `Doctrine\ORM\Query` class represents a DQL query. You create
     // example1: passing a DQL string
     $q = $em->createQuery('select u from MyProject\Model\User u');
 
-    // example2: usin setDql
+    // example2: using setDql
     $q = $em->createQuery();
     $q->setDql('select u from MyProject\Model\User u');
 
@@ -612,7 +612,7 @@ The use of the methods mentioned earlier is generally preferred as it leads to m
 
 +++ Pure and Mixed Results
 
-The nature of a result returned by a DQL SELECT query retrieved through `Query#getResult()` or `Query#getArrayResult()` can be of 2 forms: **pure** and **mixed**. In the previous simple examples, you already saw a "pure" query result, with only objects. By default, the result type is **pure** but **as soon as scalar values, such as aggregate values or other scalar values that do not belong to an entity, appear in the SELECT part of the DQL query, the result becomes mixed**. A mixed result has a different structure than a pure result in order to accomodate for the scalar values.
+The nature of a result returned by a DQL SELECT query retrieved through `Query#getResult()` or `Query#getArrayResult()` can be of 2 forms: **pure** and **mixed**. In the previous simple examples, you already saw a "pure" query result, with only objects. By default, the result type is **pure** but **as soon as scalar values, such as aggregate values or other scalar values that do not belong to an entity, appear in the SELECT part of the DQL query, the result becomes mixed**. A mixed result has a different structure than a pure result in order to accommodate for the scalar values.
 
 A pure result usually looks like this:
 
@@ -755,10 +755,10 @@ Now the hydrator is ready to be used in your queries:
     $query = $em->createQuery('SELECT u FROM CmsUser u');
     $results = $query->getResult('CustomHydrator');
 
-+++ Iterating Large Resultsets
++++ Iterating Large Result Sets
 
 There are situations when a query you want to execute returns a very large result-set that needs
-to be processed. All the previously described hydration modes completly load a result-set into
+to be processed. All the previously described hydration modes completely load a result-set into
 memory which might not be feasible with large result sets. See the [Batch Processing](batch-processing)
 section on details how to iterate large result sets.
 
@@ -818,10 +818,10 @@ are to be used in userland:
 hint can be used to handle memory consumption problems with large result-sets that contain char or binary data.
 Doctrine has no way of implicitly reloading this data. Partially loaded objects have to be passed to
 `EntityManager::refresh()` if they are to be reloaded fully from the database.
-* Query::HINT_REFRESH - This query is used internally by `EntityManager::refresh()` and can be used in userland aswell.
+* Query::HINT_REFRESH - This query is used internally by `EntityManager::refresh()` and can be used in userland as well.
 If you specify this hint and a query returns the data for an entity that is already managed by the UnitOfWork, the
 fields of the existing entity will be refreshed. In normal operation a result-set that loads data of an already existing
-entity is discarded in favour of the already existing entity.
+entity is discarded in favor of the already existing entity.
 * Query::HINT_CUSTOM_TREE_WALKERS - An array of additional `Doctrine\ORM\Query\TreeWalker` instances that are attached
 to the DQL query parsing process.
 
@@ -845,7 +845,7 @@ of the Query Cache, however if you do there are several methods to interact with
 
 ++++ First and Max Result Items (DQL Query Only)
 
-You can limit the number of results returned from a DQL query aswell as specify the starting offset, Doctrine
+You can limit the number of results returned from a DQL query as well as specify the starting offset, Doctrine
 then uses a strategy of manipulating the select query to return only the requested number of results:
 
 * `Query::setMaxResults($maxResults)`
@@ -854,7 +854,7 @@ then uses a strategy of manipulating the select query to return only the request
 > **NOTE**
 > If your query contains a fetch-joined collection specifying the result limit methods are not working
 > as you would expect. Set Max Results restricts the number of database result rows, however in the
-> case of fetch-joined collections one root entity might appear in many rows, effectivly hydrating
+> case of fetch-joined collections one root entity might appear in many rows, effectively hydrating
 > less than the specified number of results.
 
 ++ EBNF
@@ -866,8 +866,8 @@ The following context-free grammar, written in an EBNF variant, describes the Do
 * non-terminals begin with an upper case character
 * terminals begin with a lower case character
 * parentheses (...) are used for grouping
-* square brackets [...] are used for defining an optional part, eg. zero or one time
+* square brackets [...] are used for defining an optional part, e.g. zero or one time
-* curly brackets {...} are used for repetion, eg. zero or more times
+* curly brackets {...} are used for repetition, e.g. zero or more times
 * double quotation marks "..." define a terminal string a vertical bar | represents an alternative
 
 +++ Terminals
@@ -901,7 +901,7 @@ The following context-free grammar, written in an EBNF variant, describes the Do
     AbstractSchemaName ::= identifier
 
     /* identifier that must be a field (the "name" of "u.name") */
-    /* This is responsable to know if the field exists in Object, no matter if it's a relation or a simple field */
+    /* This is responsible to know if the field exists in Object, no matter if it's a relation or a simple field */
     FieldIdentificationVariable ::= identifier
 
     /* identifier that must be a collection-valued association field (to-many) (the "Phonenumbers" of "u.Phonenumbers") */

manual/en/events.txt

@@ -111,7 +111,7 @@ The EntityManager and UnitOfWork trigger a bunch of events during the life-time
 * postUpdate - The postUpdate event occurs after the database update operations to entity data.
 * postLoad - The postLoad event occurs for an entity after the entity has been loaded into the current EntityManager from the database or after the refresh operation has been applied to it.
 * loadClassMetadata - The loadClassMetadata event occurs after the mapping metadata for a class has been loaded from a mapping source (annotations/xml/yaml).
-* onFlush - The onFlush event occours after the change-sets of all managed entities are computed. This event is not a lifecycle callback.
+* onFlush - The onFlush event occurs after the change-sets of all managed entities are computed. This event is not a lifecycle callback.
 
 > **CAUTION**
 > Note that the postLoad event occurs for an entity before any associations have been
@@ -126,8 +126,8 @@ You can access the Event constants from the `Events` class in the ORM package.
 
 These can be hooked into by two different types of event listeners:
 
-* Lifecycle Callbacks are methods on the entity classes that are called when the event is triggered. They recieve absolutely no arguments and are specifically designed to allow changes inside the entity classes state.
+* Lifecycle Callbacks are methods on the entity classes that are called when the event is triggered. They receive absolutely no arguments and are specifically designed to allow changes inside the entity classes state.
-* Lifecycle Event Listeners are classes with specific callback methods that recieves some kind of `EventArgs` instance which give access to the entity, EntityManager or other relevant data.
+* Lifecycle Event Listeners are classes with specific callback methods that receives some kind of `EventArgs` instance which give access to the entity, EntityManager or other relevant data.
 
 > **NOTE**
 > All Lifecycle events that happen during the `flush()` of an EntityManager have very specific constraints on the allowed
@@ -249,7 +249,7 @@ the event type. The allowed event types are the ones listed in the previous Life
 ++ Listening to Lifecycle Events
 
 Lifecycle event listeners are much more powerful than the simple lifecycle callbacks that are defined on the entity
-classes. They allow to implement re-usable behaviours between different entity classes, yet require much more detailed
+classes. They allow to implement re-usable behaviors between different entity classes, yet require much more detailed
 knowledge about the inner workings of the EntityManager and UnitOfWork. Please read the *Implementing Event Listeners*
 section carefully if you are trying to write your own listener.
 
@@ -420,7 +420,7 @@ to call:
 
         private function validateCreditCard($no)
         {
-            // throw an exception to interupt flush event. Transaction will be rolled back.
+            // throw an exception to interrupt flush event. Transaction will be rolled back.
         }
     }