Fix style and linewrapping & add links in translation doc.

docs/translating.md

@@ -1,6 +1,6 @@
 # Translating Zulip
 
-Zulip has full support for unicode, so you can already use your
+Zulip has full support for Unicode, so you can already use your
 preferred language everywhere in Zulip.
 
 To make Zulip even better for users around the world, the Zulip UI is
@@ -24,7 +24,8 @@ contribute.
 ## Setting Default Language in Zulip
 
 Zulip allows you to set the default language through the settings
-page under 'Display Settings' section.
+page, in the 'Display Settings' section. The URL will be
+`/#settings/display-settings` on your realm.
 
 ## Translation Resource Files
 
@@ -48,17 +49,20 @@ idiosyncrasy is also handled in the Transifex config file.
 
 The end-to-end process to get the translations working is as follows:
 
-1. Mark the strings for translations (see sections for backend and
+1. Mark the strings for translations (see sections for
-   frontend translations for details on this).
+   [backend](#backend-translations) and
+   [frontend](#frontend-translations) translations for details on
+   this).
 
-2. Create JSON formatted [resource][] files using the `python manage makemessages`
+2. Create JSON formatted [resource][] files using the `python manage
-   command. This command will create a resource file called `translations.json`
+   makemessages` command. This command will create a resource file
-   for frontend and `django.po` for backend for every language under
+   called `translations.json` for frontend and `django.po` for backend
-   `static/locale`. The location for frontend resource file can be
+   for every language under `static/locale`. The location for frontend
-   changed by passing an argument to the command (see the help for the
+   resource file can be changed by passing an argument to the command
-   command for further details). However, make sure that the location
+   (see the help for the command for further details). However, make
-   is publicly accessible since frontend files are loaded through XHR
+   sure that the location is publicly accessible since frontend files
-   in the frontend which will only work with publicly accessible resources.
+   are loaded through XHR in the frontend which will only work with
+   publicly accessible resources.
 
    The `makemessages` command is idempotent in that:
 
@@ -116,8 +120,9 @@ You can instead use:
 ```
 
 Zulip expects all the error messages to be translatable as well.  To
-ensure this, the error message passed to `json_error` and `JsonableError`
+ensure this, the error message passed to `json_error` and
-should always be a literal string enclosed by `_()` function, e.g:
+`JsonableError` should always be a literal string enclosed by `_()`
+function, e.g.:
 
 ```
 json_error(_('English Text'))
@@ -131,18 +136,20 @@ Zulip linter (`tools/lint-all`) checks for correct usage.
 
 Zulip uses the [i18next][] library for frontend translations. There
 are two types of files in Zulip frontend which can hold translatable
-strings, JavaScript code files and Handlebar templates. To mark a
+strings: JavaScript code files and Handlebar templates. To mark a
-string translatable in JavaScript files pass it to the `i18n.t` function.
+string translatable in JavaScript files, pass it to the `i18n.t`
+function.
 
 ```
 i18n.t('English Text', context);
 i18n.t('English text with a __variable__', {'variable': 'Variable value'});
 ```
 
-Note: In the second example above, instead of enclosing the variable with
+Note: In the second example above, instead of enclosing the variable
-handlebars, `{{ }}`, we enclose it with `__` because we need to
+with handlebars, `{{ }}`, we enclose it with `__` because we need to
-differentiate the variable from the Handlebar tags. The symbol which is
+differentiate the variable from the Handlebar tags. The symbol which
-used to enclose the variables can be changed in `/static/js/src/main.js`.
+is used to enclose the variables can be changed in
+`/static/js/src/main.js`.
 
 `i18next` also supports plural translations. To support plurals make
 sure your resource file contatins the related keys:
@@ -196,8 +203,8 @@ var context = {'variable': 'variable value'};
 ```
 
 The rules for plurals are same as for JavaScript files. You just have
-to declare the appropriate keys in the resource file and then include the
+to declare the appropriate keys in the resource file and then include
-`count` in the context.
+the `count` in the context.
 
 
 [Django]: https://docs.djangoproject.com/en/1.9/topics/templates/#the-django-template-language
@@ -219,20 +226,20 @@ Django figures out the effective language by going through the
 following steps:
 
 1. It looks for the language code in the url.
-2. It looks for the LANGUGE_SESSION_KEY key in the current user's
+2. It looks for the `LANGUAGE_SESSION_KEY` key in the current user's
 session.
 3. It looks for the cookie named 'django_language'. You can set a
-different name through LANGUAGE_COOKIE_NAME setting.
+different name through the `LANGUAGE_COOKIE_NAME` setting.
 4. It looks for the `Accept-Language` HTTP header in the HTTP request.
 Normally your browser will take care of this.
 
-The easiest way to test translations is through the i18n urls e.g. if
+The easiest way to test translations is through the i18n URLs, e.g.,
-you have German translations available you can access the German
+if you have German translations available, you can access the German
-version of a page by going to `/de/path_to_page`.
+version of a page by going to `/de/path_to_page` in your browser.
 
 To test translations using other methods you will need an HTTP client
-library like `requests`, `cURL` or `urllib`. Here is a sample code to
+library like `requests`, `cURL` or `urllib`. Here is some sample code
-test `Accept-Language` header using requests:
+to test `Accept-Language` header using Python and `requests`:
 
 ```
 import requests