Docs: Fix typos in docs.

docs/code-style.md

@@ -362,7 +362,7 @@ Version Control
 We follow the Git project's own commit discipline practice of "Each
 commit is a minimal coherent idea". This discipline takes a bit of work,
 but it makes it much easier for code reviewers to spot bugs, and
-makesthe commit history a much more useful resource for developers
+makes the commit history a much more useful resource for developers
 trying to understand why the code works the way it does, which also
 helps a lot in preventing bugs.
 

docs/markdown.md

@@ -94,7 +94,7 @@ be non-standard.
 * Allow tacking a bulleted list or block quote onto the end of a
   paragraph, i.e. without a blank line before it
 
-* Allow only `*` for bulleted lists, not `+` or `-` (previoulsy
+* Allow only `*` for bulleted lists, not `+` or `-` (previously
   created confusion with diff-style text sloppily not included in a
   code block)
 

docs/new-feature-tutorial.md

@@ -85,7 +85,7 @@ Then create a Django migration that adds a new field,
 In `zerver/lib/actions.py`, create a new function named
 `do_set_realm_invite_by_admins_only`. This function will update the
 database and trigger an event to notify clients when this setting
-changes. In this case there was an exisiting `realm|update` event type
+changes. In this case there was an existing `realm|update` event type
 which was used for setting similar flags on the Realm model, so it was
 possible to add a new property to that event rather than creating a new
 one. The property name matches the database field to make it easy to
@@ -134,7 +134,7 @@ newly-added `actions.py` code to update the database. This example
 feature adds a new parameter that should be sent to clients when the
 application loads and be accessible via JavaScript, and there is already
 a view that does this for related flags: `update_realm`. So in this
-case, we can add out code to the exisiting view instead of creating a
+case, we can add out code to the existing view instead of creating a
 new one. :
 
     # zerver/views/__init__.py

docs/roadmap.md

@@ -18,7 +18,7 @@ together a roadmap detailing the major areas where the project is
 hoping to improve.  This can be especially important in an open source
 project like Zulip where development is distributed across many people
 around the world.  This roadmap is intended to organize a list of the
-most important improvements that should to be made to Zulip in the
+most important improvements that should be made to Zulip in the
 relatively near future.  Our aim is to complete most of these
 improvements in 2016.
 

docs/testing.md

@@ -192,7 +192,7 @@ for writing Casper tests in addition to the debugging notes below:
     and the various assert statements available are documented here:
     <http://docs.casperjs.org/en/latest/modules/tester.html#the-tester-prototype>
 -   Casper uses CSS3 selectors; you can often save time by testing and
-    debugigng your selectors on the relevant page of the Zulip
+    debugging your selectors on the relevant page of the Zulip
     development app in the Chrome javascript console by using e.g.
     `$$("#settings-dropdown")`.
 -   The test suite uses a smaller set of default user accounts and other

docs/translating.md

@@ -63,8 +63,8 @@ The first step in translating the frontend is to create the translation
 files using `python manage makemessages`. This command will create
 translation files under `static/locale`, the location can be changed by
 passing an argument to the command, however make sure that the location is
-publically accessible since these files are loaded through XHR in the
+publicly accessible since these files are loaded through XHR in the
-frontend which will only work with publically accessible resources.
+frontend which will only work with publicly accessible resources.
 
 The second step is to upload the translatable strings to Transifex using
 `tx push -s -a`.