HSEARCH-1831 Correcting various typos in the documentation (ported fr…

…om contribution to docbook version of docs)

documentation/src/main/asciidoc/architecture.asciidoc

@@ -29,7 +29,7 @@ your own IndexManager implementation (see <<configuration-indexmanager>>).
 
 Once the index is created, you can search for entities and return lists of managed entities saving
 you the tedious object to Lucene Document mapping. The same persistence context is shared between
-Hibernate and Hibernate Search. As a matter of fact, the FullTextSession is built on top of the
+Hibernate and Hibernate Search. As a matter of fact, the `FullTextSession` is built on top of the
 Hibernate Session so that the application code can use the unified org.hibernate.Query or
 javax.persistence.Query APIs exactly the same way a HQL, JPA-QL or native query would do.
 

documentation/src/main/asciidoc/configuration.asciidoc

@@ -193,7 +193,7 @@ by this DirectoryProvider. Allowed values are `auto` (the default value, selects
 non Windows systems, SimpleFSDirectory on Windows), `simple` (SimpleFSDirectory),
 `nio` (NIOFSDirectory), `mmap` (MMapDirectory). Make sure to refer to Javadocs of these Directory
 implementations before changing this setting. Even though NIOFSDirectory or MMapDirectory can bring
-substantial performace boosts they also have their issues.
+substantial performance boosts they also have their issues.
 
 |filesystem-master: File system based directory.
 
@@ -225,7 +225,7 @@ this DirectoryProvider. Allowed values are `auto` (the default value, selects NI
 Windows systems, SimpleFSDirectory on Windows), `simple` (SimpleFSDirectory),
 `nio` (NIOFSDirectory), `mmap` (MMapDirectory). Make sure to refer to Javadocs of these
 Directory implementations before changing this setting. Even though NIOFSDirectory or MMapDirectory
-can bring substantial performace boosts they also have their issues.
+can bring substantial performance boosts they also have their issues.
 
 |filesystem-slave: File system based directory.
 
@@ -256,7 +256,7 @@ defaults to 16MB.
 in the source directory before failing. Waiting 5 seconds between each try.
 `retry_initialize_period` : optional, set an integer value in seconds to enable the retry initialize
 feature: if the slave can't find the master index it will try again until it's found in background,
-without preventing the application to start: fullText queries performed before the index is
+without preventing the application to start: full-text queries performed before the index is
 initialized are not blocked but will return empty results. When not enabling the option or
 explicitly setting it to zero it will fail with an exception instead of scheduling a retry timer.
 To prevent the application from starting without an invalid index but still control an
@@ -266,7 +266,7 @@ used by this DirectoryProvider. Allowed values are `auto` (the default value, se
 on non Windows systems, SimpleFSDirectory on Windows), `simple` (SimpleFSDirectory), `nio`
 (NIOFSDirectory), `mmap` (MMapDirectory). Make sure to refer to Javadocs of these Directory
 implementations before changing this setting. Even though NIOFSDirectory or MMapDirectory can bring
-substantial performace boosts they also have their issues.
+substantial performance boosts they also have their issues.
 
 |infinispan: Infinispan based directory.
 
@@ -937,7 +937,7 @@ Alternatively, an ErrorHandler instance may be passed via the configuration valu
 
 Even though Hibernate Search will try to shield you as much as possible from Lucene specifics, there
 are several Lucene specifics which can be directly configured, either for performance reasons or for
-satisfying a specific usecase. The following sections discuss these configuration options.
+satisfying a specific use case. The following sections discuss these configuration options.
 
 [[lucene-indexing-performance]]
 
@@ -1270,7 +1270,7 @@ Hibernate Search, make sure to apply the same value too.
 === Metadata API
 
 After looking at all these different configuration options, it is time to have a look at an API
-which allows you to prorgammatically access parts of the configuration. Via the metadata API you can
+which allows you to programmatically access parts of the configuration. Via the metadata API you can
 determine the indexed types and also how they are mapped (see <<search-mapping>>) to the index
 structure. The entry point into this API is the SearchFactory. It offers two methods, namely
 `getIndexedTypes()` and `getIndexedTypeDescriptor(Class<?>)`. The former returns a set of all

documentation/src/main/asciidoc/getting-started.asciidoc

@@ -345,7 +345,7 @@ the indexed fields, execute it and return a list of `Book` instances.
 FullTextSession fullTextSession = Search.getFullTextSession(session);
 Transaction tx = fullTextSession.beginTransaction();
 
-// create native Lucene query unsing the query DSL
+// create native Lucene query using the query DSL
 // alternatively you can write the Lucene query using the Lucene query parser
 // or the Lucene programmatic API. The Hibernate Search DSL is recommended though
 QueryBuilder qb = fullTextSession.getSearchFactory()
@@ -377,7 +377,7 @@ FullTextEntityManager fullTextEntityManager =
     org.hibernate.search.jpa.Search.getFullTextEntityManager(em);
 em.getTransaction().begin();
 
-// create native Lucene query unsing the query DSL
+// create native Lucene query using the query DSL
 // alternatively you can write the Lucene query using the Lucene query parser
 // or the Lucene programmatic API. The Hibernate Search DSL is recommended though
 QueryBuilder qb = fullTextEntityManager.getSearchFactory()
@@ -446,7 +446,8 @@ distribution.
 In the example below a `StandardTokenizerFactory` is used followed by two filter factories,
 `LowerCaseFilterFactory` and `SnowballPorterFilterFactory`. The standard tokenizer splits words at
 punctuation characters and hyphens while keeping email addresses and internet hostnames intact. It
-is a good general purpose tokenizer. The lowercase filter lowercases the letters in each token
+is a good general purpose tokenizer.
+The lowercase filter converts to lowercase the letters in each token
 whereas the snowball filter finally applies language specific stemming.
 
 Generally, when using the Analyzer Framework you have to start with a tokenizer followed by an

documentation/src/main/asciidoc/mapping.asciidoc

@@ -915,7 +915,7 @@ Some of the analyzers and filters will require additional dependencies. For exam
 snowball stemmer you have to also include the `lucene-snowball` jar and for the
 PhoneticFilterFactory you need the link:http://commons.apache.org/codec[commons-codec] jar. Your
 distribution of Hibernate Search provides these dependencies in its _lib/optional_ directory. Have a
-look at <<table-available-tokenizers>> and <<table-available-filters>> to see which anaylzers and
+look at <<table-available-tokenizers>> and <<table-available-filters>> to see which analyzers and
 filters have additional dependencies
 
 Prior to Hibernate Search 5 it was required to add the Apache Solr dependency to your project as
@@ -2013,10 +2013,10 @@ sometimes more convenient to use a different approach:
 
 
 * the same entity is mapped differently depending on deployment needs (customization for clients)
-* some automatization process requires the dynamic mapping of many entities sharing common traits
+* some automation process requires the dynamic mapping of many entities sharing common traits
 
 While it has been a popular demand in the past, the Hibernate team never found the idea of an XML
-alternative to annotations appealing due to it's heavy duplication, lack of code refactoring safety,
+alternative to annotations appealing due to its heavy duplication, lack of code refactoring safety,
 because it did not cover all the use case spectrum and because we are in the 21st century :)
 
 The idea of a programmatic API was much more appealing and has now become a reality. You can
@@ -2332,7 +2332,7 @@ public class Address {
  @Id
  @GeneratedValue
  @DocumentId(name="id")
- pubblic Long getAddressId() {...};
+ public Long getAddressId() {...};
 
  @Fields({
       @Field(store=Store.YES, analyzer=@Analyzer(definition="en")),

documentation/src/main/asciidoc/spatial.asciidoc

@@ -1,7 +1,7 @@
 [[spatial]]
 == Spatial
 
-With the spatial extensions you can combine fulltext queries with distance restrictions, filter results based on distances
+With the spatial extensions you can combine full-text queries with distance restrictions, filter results based on distances
 or sort results on such a distance criteria.
 
 The spatial support of Hibernate Search has the following goals:
@@ -122,7 +122,7 @@ public class Hotel {
 
 ==== Implementing the Coordinates interface
 
-Instead of using the `@Latitude` and `@Longitue` annotations you can choose to implement the
+Instead of using the `@Latitude` and `@Longitude` annotations you can choose to implement the
 `org.hibernate.search.spatial.Coordinates` interface.
 
 .Implementing the Coordinates interface
@@ -213,7 +213,7 @@ When using this form the `@Spatial.name` automatically defaults to the property
 You can use the Hibernate Search query DSL to build a query to search around a pair of coordinates (latitude, longitude)
 or around a bean implementing the `Coordinates` interface.
 
-As with any fulltext query, the spatial query creation flow looks like:
+As with any full-text query, the spatial query creation flow looks like:
 
 . retrieve a `QueryBuilder` from the `SearchFactory`
 . use the DSL to build a spatial query, defining search center and radius