Merge pull request django-haystack#660 from seldon/master

bigjust · bigjust · commit 761d4ac9e47d · 2013-05-17T11:55:11.000-07:00
Some minor docs fixes
diff --git a/docs/boost.rst b/docs/boost.rst
@@ -23,7 +23,7 @@ Despite all being types of boost, they take place at different times and have
 slightly different effects on scoring.
 
 Term boost happens at query time (when the search query is run) and is based
-around increasing the score is a certain word/phrase is seen.
+around increasing the score if a certain word/phrase is seen.
 
 On the other hand, document & field boosts take place at indexing time (when
 the document is being added to the index). Document boost causes the relevance
diff --git a/docs/faceting.rst b/docs/faceting.rst
@@ -8,7 +8,7 @@ What Is Faceting?
 -----------------
 
 Faceting is a way to provide users with feedback about the number of documents
-which match terms they may be interested in. At it's simplest, it gives
+which match terms they may be interested in. At its simplest, it gives
 document counts based on words in the corpus, date ranges, numeric ranges or
 even advanced queries.
 
diff --git a/docs/glossary.rst b/docs/glossary.rst
@@ -4,7 +4,7 @@
 Glossary
 ========
 
-Search is a domain full of it's own jargon and definitions. As this may be an
+Search is a domain full of its own jargon and definitions. As this may be an
 unfamiliar territory to many developers, what follows are some commonly used
 terms and what they mean.
 
diff --git a/docs/inputtypes.rst b/docs/inputtypes.rst
@@ -125,7 +125,7 @@ Example::
 
 .. class:: haystack.inputs.AltParser
 
-``AltParser`` let's you specify that a portion of the query should use a
+``AltParser`` lets you specify that a portion of the query should use a
 separate parser in the search engine. This is search-engine-specific, so it may
 decrease the portability of your app.
 
@@ -153,7 +153,7 @@ The ``prepare`` method lets you alter the query the user provided before it
 becomes of the main query. It is lazy, called as late as possible, right before
 the final query is built & shipped to the engine.
 
-A full, if somewhat silly, example look like::
+A full, if somewhat silly, example looks like::
 
     from haystack.inputs import Clean
 
diff --git a/docs/installing_search_engines.rst b/docs/installing_search_engines.rst
@@ -74,7 +74,7 @@ Something like the following is suggested::
         suggestions = indexes.FacetCharField()
 
         def prepare(self, obj):
-            prepared_data = super(NoteIndex, self).prepare(obj)
+            prepared_data = super(MySearchIndex, self).prepare(obj)
             prepared_data['suggestions'] = prepared_data['text']
             return prepared_data
 
diff --git a/docs/searchbackend_api.rst b/docs/searchbackend_api.rst
@@ -58,7 +58,7 @@ specific to each one.
 
 .. method:: SearchBackend.search(self, query_string, sort_by=None, start_offset=0, end_offset=None, fields='', highlight=False, facets=None, date_facets=None, query_facets=None, narrow_queries=None, spelling_query=None, limit_to_registered_models=None, result_class=None, **kwargs)
 
-Takes a query to search on and returns dictionary.
+Takes a query to search on and returns a dictionary.
 
 The query should be a string that is appropriate syntax for the backend.
 
diff --git a/docs/searchfield_api.rst b/docs/searchfield_api.rst
@@ -6,7 +6,7 @@
 
 .. class:: SearchField
 
-The ``SearchField`` and it's subclasses provides a way to declare what data
+The ``SearchField`` and its subclasses provides a way to declare what data
 you're interested in indexing. They are used with ``SearchIndexes``, much like
 ``forms.*Field`` are used within forms or ``models.*Field`` within models.
 
@@ -108,7 +108,7 @@ to be the primary field for searching within. Default is ``False``.
 
 .. attribute:: SearchField.indexed
 
-A boolean flag for indicating whether or not the the data from this field will
+A boolean flag for indicating whether or not the data from this field will
 be searchable within the index. Default is ``True``.
 
 The companion of this option is ``stored``.
@@ -162,7 +162,7 @@ not to contain any data. Default is ``False``.
 
     Unlike Django's database layer, which injects a ``NULL`` into the database
     when a field is marked nullable, ``null=True`` will actually exclude that
-    field from being included with the document. This more efficient for the
+    field from being included with the document. This is more efficient for the
     search engine to deal with.
 
 ``stored``
diff --git a/docs/searchindex_api.rst b/docs/searchindex_api.rst
@@ -107,7 +107,7 @@ However, this can also hit the database quite heavily (think
 ``.get(pk=result.id)`` per object). If your search is popular, this can lead
 to a big performance hit. There are two ways to prevent this. The first way is
 ``SearchQuerySet.load_all``, which tries to group all similar objects and pull
-them though one query instead of many. This still hits the DB and incurs a
+them through one query instead of many. This still hits the DB and incurs a
 performance penalty.
 
 The other option is to leverage stored fields. By default, all fields in
@@ -159,7 +159,7 @@ see, the churn rate of your data and what concerns are important to you
 The conventional method is to use ``SearchIndex`` in combination with cron
 jobs. Running a ``./manage.py update_index`` every couple hours will keep your
 data in sync within that timeframe and will handle the updates in a very
-efficient batch. Additionally, Whoosh (and to a lesser extent Xapian) behave
+efficient batch. Additionally, Whoosh (and to a lesser extent Xapian) behaves
 better when using this approach.
 
 Another option is to use ``RealtimeSignalProcessor``, which uses Django's
@@ -236,7 +236,7 @@ you might write the following code::
             return "%s <%s>" % (obj.user.get_full_name(), obj.user.email)
 
 This method should return a single value (or list/tuple/dict) to populate that
-fields data upon indexing. Note that this method takes priority over whatever
+field's data upon indexing. Note that this method takes priority over whatever
 data may come from the field itself.
 
 Just like ``Form.clean_FOO``, the field's ``prepare`` runs before the
diff --git a/docs/searchquery_api.rst b/docs/searchquery_api.rst
@@ -8,7 +8,7 @@
 
 The ``SearchQuery`` class acts as an intermediary between ``SearchQuerySet``'s
 abstraction and ``SearchBackend``'s actual search. Given the metadata provided
-by ``SearchQuerySet``, ``SearchQuery`` build the actual query and interacts
+by ``SearchQuerySet``, ``SearchQuery`` builds the actual query and interacts
 with the ``SearchBackend`` on ``SearchQuerySet``'s behalf.
 
 This class must be at least partially implemented on a per-backend basis, as portions
@@ -236,8 +236,8 @@ Adds a boosted term and the amount to boost it to the query.
 
 Runs a raw query (no parsing) against the backend.
 
-This method causes the SearchQuery to ignore the standard query
-generating facilities, running only what was provided instead.
+This method causes the ``SearchQuery`` to ignore the standard query-generating 
+facilities, running only what was provided instead.
 
 Note that any kwargs passed along will override anything provided
 to the rest of the ``SearchQuerySet``.
diff --git a/docs/searchqueryset_api.rst b/docs/searchqueryset_api.rst
@@ -311,7 +311,7 @@ amount of time between gaps as ``gap_by`` (one of ``'year'``, ``'month'``,
 
 You can also optionally provide a ``gap_amount`` to specify a different
 increment than ``1``. For example, specifying gaps by week (every seven days)
-would would be ``gap_by='day', gap_amount=7``).
+would be ``gap_by='day', gap_amount=7``).
 
 In the search results you get back, facet counts will be populated in the
 ``SearchResult`` object. You can access them via the ``facet_counts`` method.
@@ -544,7 +544,7 @@ for similar results. The instance you pass in should be an indexed object.
 Previously called methods will have an effect on the provided results.
 
 It will evaluate its own backend-specific query and populate the
-`SearchQuerySet`` in the same manner as other methods.
+``SearchQuerySet`` in the same manner as other methods.
 
 Example::
 
diff --git a/docs/utils.rst b/docs/utils.rst
@@ -12,7 +12,7 @@ Included here are some of the general use bits included with Haystack.
 
 .. function:: get_identifier(obj_or_string)
 
-Get an unique identifier for the object or a string representing the
+Gets an unique identifier for the object or a string representing the
 object.
 
-If not overridden, uses <app_label>.<object_name>.<pk>.
+If not overridden, uses ``<app_label>.<object_name>.<pk>``.
