Fix style and linewrapping & add links in translation doc.

This commit is contained in:
Sumana Harihareswara
2016-10-19 08:51:20 -04:00
committed by Tim Abbott
parent 8d1e87cfff
commit 8d4b32a13a

View File

@@ -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
frontend translations for details on this).
1. Mark the strings for translations (see sections for
[backend](#backend-translations) and
[frontend](#frontend-translations) translations for details on
this).
2. Create JSON formatted [resource][] files using the `python manage makemessages`
command. This command will create a resource file called `translations.json`
for frontend and `django.po` for backend for every language under
`static/locale`. The location for frontend resource file can be
changed by passing an argument to the command (see the help for the
command for further details). However, make sure that the location
is publicly accessible since frontend files are loaded through XHR
in the frontend which will only work with publicly accessible resources.
2. Create JSON formatted [resource][] files using the `python manage
makemessages` command. This command will create a resource file
called `translations.json` for frontend and `django.po` for backend
for every language under `static/locale`. The location for frontend
resource file can be changed by passing an argument to the command
(see the help for the command for further details). However, make
sure that the location is publicly accessible since frontend files
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`
should always be a literal string enclosed by `_()` function, e.g:
ensure this, the error message passed to `json_error` and
`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
string translatable in JavaScript files pass it to the `i18n.t` function.
strings: JavaScript code files and Handlebar templates. To mark a
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
handlebars, `{{ }}`, we enclose it with `__` because we need to
differentiate the variable from the Handlebar tags. The symbol which is
used to enclose the variables can be changed in `/static/js/src/main.js`.
Note: In the second example above, instead of enclosing the variable
with handlebars, `{{ }}`, we enclose it with `__` because we need to
differentiate the variable from the Handlebar tags. The symbol which
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
`count` in the context.
to declare the appropriate keys in the resource file and then include
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
you have German translations available you can access the German
version of a page by going to `/de/path_to_page`.
The easiest way to test translations is through the i18n URLs, e.g.,
if you have German translations available, you can access the German
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
test `Accept-Language` header using requests:
library like `requests`, `cURL` or `urllib`. Here is some sample code
to test `Accept-Language` header using Python and `requests`:
```
import requests