Fix minor typos in the FAQ and user guide

docs/faq.rst

@@ -175,7 +175,7 @@ See :ref:`brokers` for more information.
 Redis as a broker won't perform as well as
 an AMQP broker, but the combination RabbitMQ as broker and Redis as a result
 store is commonly used. If you have strict reliability requirements you're
-encouraged to use RabbitMQ or another AMQP broker. Some transports also uses
+encouraged to use RabbitMQ or another AMQP broker. Some transports also use
 polling, so they're likely to consume more resources. However, if you for
 some reason aren't able to use AMQP, feel free to use these alternatives.
 They will probably work fine for most use cases, and note that the above
@@ -195,7 +195,7 @@ language has an AMQP client, there shouldn't be much work to create a worker
 in your language. A Celery worker is just a program connecting to the broker
 to process messages.
 
-Also, there's another way to be language independent, and that's to use REST
+Also, there's another way to be language-independent, and that's to use REST
 tasks, instead of your tasks being functions, they're URLs. With this
 information you can even create simple web servers that enable preloading of
 code. Simply expose an endpoint that performs an operation, and create a task

docs/internals/guide.rst

@@ -176,7 +176,7 @@ a large potential user base.
 
 In Django there's a global settings object, so multiple Django projects
 can't co-exist in the same process space, this later posed a problem
-for using Celery with frameworks that doesn't have this limitation.
+for using Celery with frameworks that don't have this limitation.
 
 Therefore the app concept was introduced. When using apps you use 'celery'
 objects instead of importing things from Celery sub-modules, this