HHH-11547 fix some typos in documentation

documentation/src/main/asciidoc/topical/bootstrap/JpaBootstrapping.adoc

@@ -3,7 +3,7 @@
 
 Bootstrapping Hibernate as a JPA provider can be done in a JPA-spec compliant manner or using a proprietary
 bootstrapping approach.  The standardized approach has some limitations in certain environments.  But aside from
-those limitations, it is *highly* recommended that you use JPA-standardized boostrapping.
+those limitations, it is *highly* recommended that you use JPA-standardized bootstrapping.
 
 NOTE: Under the covers, all of Hibernate's JPA bootstrapping makes use of its core bootstrapping.  Be sure to see
 the _Native Bootstrapping_ guide as well.

documentation/src/main/asciidoc/topical/generated/GeneratedValues.adoc

@@ -14,7 +14,7 @@ statement.
 == Legacy support (in-database generation)
 
 Historically applications would have to manually refresh the state of any entities that included such generated values
-to account for these generated values.  Starting in version 3.2, however, Hibernate began allowing the aplication to
+to account for these generated values.  Starting in version 3.2, however, Hibernate began allowing the application to
 mark attributes as generated, which allows the application to delegate this responsibility to Hibernate.  When
 Hibernate issues an SQL INSERT or UPDATE for an entity that has defined in-database value generation, it immediately
 issues a select afterwards to retrieve the generated values.

documentation/src/main/asciidoc/topical/logging/Logging.adoc

@@ -58,7 +58,7 @@ JDK Logging would be used if none of the other framework jars are available.
 == Log Categories of Interest
 
 It is recommended that you familiarize yourself with the log messages sent from Hibernate.  A lot of work has been put
-into making the Hibernate loggiong as detailed as possible, without making it unreadable.  It is an essential
+into making the Hibernate logging as detailed as possible, without making it unreadable.  It is an essential
 troubleshooting device.  Some log categories of particular interest include:
 
 .Hibernate Log Categories of Interest

documentation/src/main/asciidoc/userguide/chapters/domain/basic_types.adoc

@@ -46,7 +46,7 @@ Internally Hibernate uses a registry of basic types when it needs to resolve a s
 |BlobType |BLOB |java.sql.Blob |blob, java.sql.Blob
 |ClobType |CLOB |java.sql.Clob |clob, java.sql.Clob
 |BinaryType |VARBINARY |byte[] |binary, byte[]
-|MaterializedBlobType |BLOB |byte[] |materized_blob
+|MaterializedBlobType |BLOB |byte[] |materialized_blob
 |ImageType |LONGVARBINARY |byte[] |image
 |WrapperBinaryType |VARBINARY |java.lang.Byte[] |wrapper-binary, Byte[], java.lang.Byte[]
 |CharArrayType |VARCHAR |char[] |characters, char[]

documentation/src/main/asciidoc/userguide/chapters/query/hql/HQL.adoc

@@ -1811,7 +1811,7 @@ include::{sourcedir}/HQLTest.java[tags=hql-order-by-example]
 === Read-only entities
 
 As explained in <<chapters/domain/immutability.adoc#entity-immutability,entity immutability>> section, fetching entities in read-only mode is much more efficient than fetching read-write entities.
-Even if the entities are mutable, you can still fetch them in read-only mode, and benefit from reducing the memory footprint and sepeding up the flushing process.
+Even if the entities are mutable, you can still fetch them in read-only mode, and benefit from reducing the memory footprint and speeding up the flushing process.
 
 Read-only entities are skipped by the dirty checking mechanism as illustrated by the following example:
 

documentation/src/main/docbook/manual-old/en-US/content/portability.xml

@@ -86,7 +86,7 @@
 
         <para>
             When considering portability between databases, another important decision is selecting the
-            identifier generation stratagy you want to use.  Originally Hibernate provided the
+            identifier generation strategy you want to use.  Originally Hibernate provided the
             <emphasis>native</emphasis> generator for this purpose, which was intended to select between
             a <emphasis>sequence</emphasis>, <emphasis>identity</emphasis>, or <emphasis>table</emphasis>
             strategy depending on the capability of the underlying database.  However, an insidious implication

documentation/src/main/docbook/userGuide/en-US/chapters/portability/Portability.xml

@@ -86,7 +86,7 @@
 
         <para>
             When considering portability between databases, another important decision is selecting the
-            identifier generation stratagy you want to use.  Originally Hibernate provided the
+            identifier generation strategy you want to use.  Originally Hibernate provided the
             <emphasis>native</emphasis> generator for this purpose, which was intended to select between
             a <emphasis>sequence</emphasis>, <emphasis>identity</emphasis>, or <emphasis>table</emphasis>
             strategy depending on the capability of the underlying database.  However, an insidious implication

migration-guide.adoc

@@ -64,7 +64,7 @@ implement JPA methods now in core I decided to implement more of a composition a
 
 In Hibernate 4.3, dialect implementations that did not support a limit offset would fetch all rows for a query and
 perform pagination in-memory.  This solution, while functional, could have severe performance penalties.  In 5.x,
-we prefered to favor performance optimizations which meant dialect implementations would throw an exception if a
+we preferred to favor performance optimizations which meant dialect implementations would throw an exception if a
 limit offset was specified but the dialect didn't support such syntax.
 
 As of 5.2.5.Final, we have introduced a new setting, `hibernate.legacy_limit_handler`, that is designed to allow
@@ -91,7 +91,7 @@ dialects remain unchanged, e.g. SQLServer2005Dialect.
 * todo : merge AvailableSettings together
 * org.hibernate.Transaction now extends JPA's EntityTransaction and follows its pre- and post- assertions.
 	e.g. begin() now throws an exception if transaction is already active.
-* (todo) following the above one, JPA also says that only PersistenceUnitTransactionType#JTA EntiytManagers
+* (todo) following the above one, JPA also says that only PersistenceUnitTransactionType#JTA EntityManagers
 	are allowed to access EntityTransactions.  Need a strategy to handle this
 * Session#getFlushMode and Query#getFlushMode clash in terms of Hibernate (FlushMode) and JPA (FlushModeType)
 	returns.  #getFlushMode has been altered to return JPA's FlushModeType.  The Hibernate FlushMode