Possession and allowance on its and lets

- Its is the possessive one,
  it's the contraction
- Lets is an allowance for things,
  let's usually warms our introduction

Fixes #77

source/adjustments.textile

@@ -47,7 +47,7 @@ This may seem somewhat simplistic at first but our experience has shown that mos
 
 h4. Taxation
 
-Tax adjustments are any adjustments with a label of "Tax."  This is just a naming convention but its a standard enough case that we have a built in scope for them in Spree.  You can use the following console command to list an order's tax adjustments:
+Tax adjustments are any adjustments with a label of "Tax."  This is just a naming convention but it's a standard enough case that we have a built in scope for them in Spree.  You can use the following console command to list an order's tax adjustments:
 
 <shell>
 >> Spree::Order.last.adjustments.tax
@@ -58,7 +58,7 @@ INFO: Tax related charges are considered "frozen":adjustments.html#frozen-adjust
 
 h4. Shipping
 
-Shipping adjustments are any adjustments with a label of "Shipping."  This is just a naming convention but its a standard enough case that we have a built in scope for them in Spree.  You can use the following console command to list an order's shipping adjustments:
+Shipping adjustments are any adjustments with a label of "Shipping."  This is just a naming convention but it's a standard enough case that we have a built in scope for them in Spree.  You can use the following console command to list an order's shipping adjustments:
 
 <shell>
 >> Spree::Order.last.adjustments.shipping
@@ -159,7 +159,7 @@ When a Spree class uses this helper method it automatically adds the following c
 * The ability to associate a calculator with an instance of that class (through a +has_one :calculator+ association)
 * Validation rules and the ability to accept configuration params through Rails +accepts_nested_attributes_for+
 
-Lets look at how this works with a specific example taken from the Spree source code itself.  Specifically we'll be looking at +Spree::ShippingMethod+.
+Let's look at how this works with a specific example taken from the Spree source code itself.  Specifically we'll be looking at +Spree::ShippingMethod+.
 
 <ruby>
 module Spree
@@ -171,16 +171,16 @@ module Spree
 end
 </ruby>
 
-Here we see that +Spree::ShippingMethod+ declares that its going to be involved in calculations by declaring +calculated_adjustments+ in the class definition.  What does that give us exactly?
+Here we see that +Spree::ShippingMethod+ declares that it's going to be involved in calculations by declaring +calculated_adjustments+ in the class definition.  What does that give us exactly?
 
-Lets start by firing up the Ruby console and creating a new instance of +Spree::ShippingMethod+.
+Let's start by firing up the Ruby console and creating a new instance of +Spree::ShippingMethod+.
 
 <shell>
 >> s = Spree::ShippingMethod.new
 => #<Spree::ShippingMethod id: nil, name: nil, zone_id: nil, created_at: nil, updated_at: nil, display_on: nil, shipping_category_id: nil, match_none: nil, match_all: nil, match_one: nil>
 </shell>
 
-Now we can verify that this instance of +Spree::ShippingMethod+ in fact has a +Spree::Calculator+ association (although its currently nil because we haven't assigned anything to it.)
+Now we can verify that this instance of +Spree::ShippingMethod+ in fact has a +Spree::Calculator+ association (although it's currently nil because we haven't assigned anything to it.)
 
 <shell>
 >> s.calculator
@@ -230,7 +230,7 @@ Use of the +calculated_adjustments+ helper also provides additional methods to i
 |+update_adjustment+|Updates the amount of the adjustment using the instance's +Calculator+|
 |+calculator_type+|Utility method to help with admin screens that need to set the +Calculator+ for a particular instance of the class.|
 
-The +create_adjustment+ is the process by which all adjustments should be created.  Lets take a look at how this mechanism works inside the +Spree::Order+ class.
+The +create_adjustment+ is the process by which all adjustments should be created.  Let's take a look at how this mechanism works inside the +Spree::Order+ class.
 
 <ruby>
 def create_tax_charge!
@@ -256,7 +256,7 @@ def compute(object = nil)
 end
 </ruby>
 
-This calculator basically just returns the same amount every time its called (note the amount is configurable of course.)  Other calculators (such as +Spree::Calculator::DefaultTax+) are a bit more interesting.
+This calculator basically just returns the same amount every time it's called (note the amount is configurable of course.)  Other calculators (such as +Spree::Calculator::DefaultTax+) are a bit more interesting.
 
 <ruby>
 def compute(computable)
@@ -296,7 +296,7 @@ h4. Locked Adjustments
 
 Spree also has the notion of so-called "locked" adjustments.  The concept behind this is there are certain types of adjustments which should never be changed once calculated.  There are also situations where it is appropriate for an adjustment that was once subject to recalculation to be recalculated.
 
-WARNING: Locked adjustments are currently considered experimental.  We're currently exploring the ability to configure Spree to honor certain locking strategies.  For instance, locking a promotion calculation in place so that its not lost if the order is updated after the promotion expires.  There are also some interesting options to allow admins with the appropriate permissions to have the ability to lock/unlock adjustments when appropriate.
+WARNING: Locked adjustments are currently considered experimental.  We're currently exploring the ability to configure Spree to honor certain locking strategies.  For instance, locking a promotion calculation in place so that it's not lost if the order is updated after the promotion expires.  There are also some interesting options to allow admins with the appropriate permissions to have the ability to lock/unlock adjustments when appropriate.
 
 h3. Configuration
 

source/checkout.textile

@@ -12,7 +12,7 @@ endprologue.
 
 h3. Overview
 
-The Spree checkout process has been designed for maximum flexibility.  Its been redesigned several times now, each iteration has benefited from the feedback of real world deployment experience.  It is relatively simple to customize the checkout process to suit your needs.  Secure transmission of customer information is possible via SSL and credit card information is never stored in the database.
+The Spree checkout process has been designed for maximum flexibility.  It's been redesigned several times now, each iteration has benefited from the feedback of real world deployment experience.  It is relatively simple to customize the checkout process to suit your needs.  Secure transmission of customer information is possible via SSL and credit card information is never stored in the database.
 
 h3. Default Checkout Steps
 
@@ -53,7 +53,7 @@ This step allows the customer to add both their billing and shipping information
 
 The address fields include a select box for choosing state/province.  The list of states will be populated via JavaScript and will contain all of the states listed in the database for the currently selected country.  If there are no states configured for a particular country, or if the user has JavaScript disabled, the select box will be replaced by a text field instead.
 
-INFO: The default "seed" data for Spree only includes the U.S. states.  Its easy enough to add states or provinces for other countries but beyond the scope of the project to maintain such a list.  Feel free to add your own seed data for the states you require (and to share your seed scripts with others via "Gist":https://gist.github.com/.)
+INFO: The default "seed" data for Spree only includes the U.S. states.  It's easy enough to add states or provinces for other countries but beyond the scope of the project to maintain such a list.  Feel free to add your own seed data for the states you require (and to share your seed scripts with others via "Gist":https://gist.github.com/.)
 
 NOTE: The state field can be disabled entirely by using the +address_requires_state+ preference.  You can also allow for an "alternate phone" field by using the +alternative_billing_phone+ and +alternative_shipping+ fields.
 
@@ -69,13 +69,13 @@ h4. Payment
 
 This step is where the customer provides payment information.  This step is intentionally placed last in order to minimize security issues with credit card information.  Credit card information is never stored in the database so it would be impossible to have a subsequent step and still be able to submit the information to the "payment gateway":payment_gateways.html.  Spree submits the information to the gateway before saving the model so that the sensitive information can be discarded before saving the checkout information.
 
-WARNING: Spree discards the credit card number after this step is processed.  If you do not have a gateway with payment profiles enabled then your card information will be lost before its time to authorize the card.
+WARNING: Spree discards the credit card number after this step is processed.  If you do not have a gateway with payment profiles enabled then your card information will be lost before it's time to authorize the card.
 
 INFO: Spree stores only the last four digits of the credit card number along with the expiration information.  The full credit card number and verification code are never stored in the Spree database.
 
 NOTE: Several gateways such as ActiveMerchant and Beanstream provide a secure method for storing a "payment profile" in your database.  This approach typically involves the use of a "token" which can be used for subsequent purchases but only with your merchant account.  If you are using a secure payment profile it would then be possible to show a final "confirmation" step after payment information is entered.
 
-NOTE: If you do not want to use a gateway with payment profiles then you will need to customize the checkout process so that your final step submits the credit card information.  You can then perform an authorization before the order is saved.  This is perfectly secure because the credit card information is not ever saved.  Its transmitted to the gateway and then discarded like normal.
+NOTE: If you do not want to use a gateway with payment profiles then you will need to customize the checkout process so that your final step submits the credit card information.  You can then perform an authorization before the order is saved.  This is perfectly secure because the credit card information is not ever saved.  It's transmitted to the gateway and then discarded like normal.
 
 h4. Confirmation
 
@@ -133,7 +133,7 @@ h4. The Order Model and State Machine
 
 The default checkout flow for the +Spree::Order+ model is defined in +app/models/spree/order/checkout.rb+ of spree_core.
 
-An +Spree::Order+ object has an initial state of 'cart'.  From there any number of events transition the +Spree::Order+ to different states.  Spree does not have a separate model or database table for the shopping cart. What the user considers a "shopping cart" is actually an in-progress +Spree::Order+.  An order is considered in-progress, or incomplete when its +completed_at+ attribute is null.  Incomplete orders can be easily filtered during reporting and its also simple enough to write a quick script to periodically purge incomplete orders from the system.  The end result is a simplified data model along with the ability for store owners to search and report on incomplete/abandoned orders.
+An +Spree::Order+ object has an initial state of 'cart'.  From there any number of events transition the +Spree::Order+ to different states.  Spree does not have a separate model or database table for the shopping cart. What the user considers a "shopping cart" is actually an in-progress +Spree::Order+.  An order is considered in-progress, or incomplete when its +completed_at+ attribute is null.  Incomplete orders can be easily filtered during reporting and it's also simple enough to write a quick script to periodically purge incomplete orders from the system.  The end result is a simplified data model along with the ability for store owners to search and report on incomplete/abandoned orders.
 
 INFO: For more information on the state machine gem please see the "README":https://github.com/pluginaweek/state_machine
 
@@ -164,7 +164,7 @@ This callback would prevent transitioning to the +delivery+ step if +valid_zip_c
 
 h5. Customizing the View for a Particular Step
 
-Each of the default checkout steps has its own partial defined in the spree_core's +app/views/spree/checkout+ directory.  Changing the view for an existing step is as simple as overriding the relevant partial in your site extension.  Its also possible the default partial in question defines a usable theme hook, in which case you could add your functionality by using "Deface":https://github.com/spree/deface.html
+Each of the default checkout steps has its own partial defined in the spree_core's +app/views/spree/checkout+ directory.  Changing the view for an existing step is as simple as overriding the relevant partial in your site extension.  It's also possible the default partial in question defines a usable theme hook, in which case you could add your functionality by using "Deface":https://github.com/spree/deface.html
 
 INFO: See also the brief discussion in "checkout partials":#checkout-partials for additional information.
 

source/contributing_to_spree.textile

@@ -46,7 +46,7 @@ You should file an issue if you have found (or suspect) a bug in the "core" func
 
 h4. Providing a Patch
 
-If you are filing and issue and supplying a patch at the same time, please file a "Pull Request":#creating-a-pull-request instead.  The pull request will also create an issue at the same time but its superior to just creating an issue because the code and issue can be linked.
+If you are filing and issue and supplying a patch at the same time, please file a "Pull Request":#creating-a-pull-request instead.  The pull request will also create an issue at the same time but it's superior to just creating an issue because the code and issue can be linked.
 
 If the ticket already exists, however, and you want to supply a patch after the fact, you can simply reference the issue number in your commit message. For example, if your commit fixed issue #123 you could use the following commit message:
 
@@ -96,7 +96,7 @@ INFO: See the GitHub guide on "creating forks":https://help.github.com/articles/
 
 h4. Topic Branches
 
-Git branches are “cheap.” Creating branches in Git is incredibly easy and its an ideal way to isolate a specific set of changes. You may be fixing several things at one time but by keeping your changes isolated it will help us to find and apply only the changes we’re interested in. You should create a clean branch based on the latest spree/master when doing this. It is important you follow these steps exactly, it will prevent you from accidentally including unrelated changes from your local repository into the branch.
+Git branches are “cheap.” Creating branches in Git is incredibly easy and it's an ideal way to isolate a specific set of changes. You may be fixing several things at one time but by keeping your changes isolated it will help us to find and apply only the changes we’re interested in. You should create a clean branch based on the latest spree/master when doing this. It is important you follow these steps exactly, it will prevent you from accidentally including unrelated changes from your local repository into the branch.
 
 For example, if we were submitting a patch to fix an issue with the CSS in the flash error message you could create a branch as follows:
 

source/deployment_application_processes.textile

@@ -110,6 +110,6 @@ end
 
 The -c (or --concurrency) switch accepts the process type and an integer for the number of processes to start up. You specify mulitple types by comma separating as follows: processname=2,processname=4
 
-WARNING: Its important to not export more than one :web process when using the default unicorn configuration, as this refers to the master process and not the workers, the worker count can be configured via the Deployment's Service UI.
+WARNING: It's important to not export more than one :web process when using the default unicorn configuration, as this refers to the master process and not the workers, the worker count can be configured via the Deployment's Service UI.
 
 .

source/deployment_tips.textile

@@ -26,13 +26,13 @@ INFO: There is a good reason why this is disabled by default in Rails which is t
 
 h5. Configure the Web Server to Use the +public+ Directory
 
-The recommended approach for handling static assets is to allow your web server to handle serving these files.  If you want to follow this approach just make sure that its configured properly in the +config/environments/production.rb+ of your Rails app.
+The recommended approach for handling static assets is to allow your web server to handle serving these files.  If you want to follow this approach just make sure that it's configured properly in the +config/environments/production.rb+ of your Rails app.
 
 <ruby>
   config.serve_static_assets = false
 </ruby>
 
-INFO: This is the default setting of Rails so its also fine if this setting is missing or commented out.
+INFO: This is the default setting of Rails so it's also fine if this setting is missing or commented out.
 
 The following is an example of how to configure Apache so that its document root is pointing to the +public+ folder.
 
@@ -105,7 +105,7 @@ To properly enable email delivery, you need to provide valid SMTP information. T
 
 Note that mail settings are configured on a per-environment basis.  This will allow you to configure the settings differently for staging or production mode.  For example, you might want to intercept all outgoing email in the staging environment and re-route it to test@yourstore.com.  This would prevent someone from accidentally sending an email to a real world customer when testing operations such as canceling an order or marking it shipped.
 
-NOTE: Its generally considered a bad idea to send email on the same "thread" as a web request.  Many web applications (including e-commerce ones) manage to get by doing this but high volume stores should consider using standard Rails techniques such as "Delayed Job":https://github.com/tobi/delayed_job for handling email delivery as a separate process.
+NOTE: It's generally considered a bad idea to send email on the same "thread" as a web request.  Many web applications (including e-commerce ones) manage to get by doing this but high volume stores should consider using standard Rails techniques such as "Delayed Job":https://github.com/tobi/delayed_job for handling email delivery as a separate process.
 
 INFO: The Spree core team is actively working on a solution for improved email processing - perhaps involving an optional extension for Delayed Job support.
 

source/getting_started.textile

@@ -121,7 +121,7 @@ Let's start by creating a standard Rails application using the following command
 rails new mystore
 </shell>
 
-This creates a new Rails application using all of the default options (including a Sqlite3 database.)  If you wish to create your application with a different database you can use the +-d+ option (again this is not specific to Spree - its standard Rails at this point.)
+This creates a new Rails application using all of the default options (including a Sqlite3 database.)  If you wish to create your application with a different database you can use the +-d+ option (again this is not specific to Spree - it's standard Rails at this point.)
 
 For example, to create your application using Mysql you use the following command instead:
 
@@ -152,7 +152,7 @@ After you create the store application, switch to its folder to continue work di
 cd mystore
 </shell>
 
-Now lets add Spree to our Rails application:
+Now let's add Spree to our Rails application:
 
 <shell>
 spree install