mirrors/django
1
0
Fork 0
mirror of https://github.com/django/django.git synced 2025-07-04 01:39:20 +00:00
Code Issues 32 Releases Wiki Activity

i18n: updated documentation and unittests for the new get_available_languages tag and the new switching view

Browse Source 
git-svn-id: http://code.djangoproject.com/svn/django/branches/i18n@1049 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
Georg Bauer 2005-11-02 17:48:49 +00:00
parent 13fcef45f7
commit a7bd5a2141
2 changed files with 31 additions and 24 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

50
docs/translation.txt
View File

@ -155,21 +155,34 @@ is a list of tuples where the first element is the language code and the
second element is the language name (in that language). The code might second element is the language name (in that language). The code might
look like this:: look like this::
<form method="POST"> <form action="/i18n/setlang/" method="POST">
<select name="django_language"> <input name="next" type="hidden" value="http://server.doma.in/path/to/go/to/after/switch/"/>
<select name="language">
{% for lang in LANGUAGES %} {% for lang in LANGUAGES %}
<option value="{{ lang.0 }}">{{ lang.1 }}</option> <option value="{{ lang.0 }}">{{ lang.1 }}</option>
{% endfor %} {% endfor %}
</select> </select>
</form> </form>
This would jump to the same page you came from and pass the django_language This would jump to a language switcher and then be redirected back to the
variable. This is used in discovery of languages, as described in the next page it came from. The switcher page will just store the language in either
chapter. Of course this can only work if your rendering context contains the users session or a special cookie for use in the language discovery.
the LANGUAGE_CODE and LANGUAGES variables. If you use DjangoContext as
your rendering context, they are automatically defined. If you use the You can leave out the "next" field. In that case the /i18n/setlang/ view
simpler Context class, you need to pass them along from request.LANGUAGE_CODE will redirect to the URL that is in the "Referer" header. Please keep in mind
and settings.LANGUAGES themselve. that people might suppress that header, so in those cases there won't be a
URL to redirect to - in those cases the view function will redirect to "/"
as a fallback.
The /i18n/setlang/ url can be set up by including the following in your
ROOT_URLCONF::
urlpatterns = patterns('',
(r'^i18n/', include('django.conf.urls.i18n'),
)
This adds the setlang handler to your urlspace and hooks up a standard view
function to it.
How the Language is Discovered How the Language is Discovered
============================== ==============================
@ -206,20 +219,11 @@ from the admin.py settings file).
The LocaleMiddleware allows a selection of the language based on data from The LocaleMiddleware allows a selection of the language based on data from
the request - every user can have her own settings. the request - every user can have her own settings.
The first thing the LocaleMiddleware does, is looking at the GET and POST The first thing the LocaleMiddleware does, it looks at the session data for the
data. If it finds a django_language variable there (if both have one, the user. If that carries a key django_language, it's contents will be used as the
one from GET will succeed), this language will be stored in the session language code. If the session doesn't contain a language setting, the
(if sessions are used in your site) or in a cookie (if you don't use middleware will look at the cookies for a django_language cookie. If that is
sessions). And it will be the selected langauge, of course. That way found, it gives the language code.
you can provide simple language switches by creating either a link with
language (linked from country flags for example) or by giving the user some
language selector like in the previous chapter.
If neither GET nor POST have django_language, the middleware looks at the
session data for the user. If that carries a key django_language, it's contents
will be used as the language code. If the session doesn't contain a language
setting, the middleware will look at the cookies for a django_language cookie.
If that is found, it gives the language code.
The format for the explicit django_language parameters is allways the The format for the explicit django_language parameters is allways the
language to use - for example it's pt-br for Brazilian. If a base language language to use - for example it's pt-br for Brazilian. If a base language

5
tests/othertests/templates.py
View File

@ -258,6 +258,9 @@ TEMPLATE_TESTS = {
# translation of a variable with a non-translated filter # translation of a variable with a non-translated filter
'i18n14': ('{{ bool|yesno:"ja,nein" }}', {'bool': True}, 'ja'), 'i18n14': ('{{ bool|yesno:"ja,nein" }}', {'bool': True}, 'ja'),
# usage of the get_available_languages tag
'i18n15': ('{% get_available_languages as langs %}{% for lang in langs %}{% ifequal lang.0 "de" %}{{ lang.0 }}{% endifequal %}{% endfor %}', {}, 'de'),
} }
def test_template_loader(template_name, template_dirs=None): def test_template_loader(template_name, template_dirs=None):
@ -277,7 +280,7 @@ def run_tests(verbosity=0, standalone=False):
tests.sort() tests.sort()
for name, vals in tests: for name, vals in tests:
if 'LANGUAGE_CODE' in vals[1]: if 'LANGUAGE_CODE' in vals[1]:
activate('*', vals[1]['LANGUAGE_CODE']) activate(vals[1]['LANGUAGE_CODE'])
try: try:
output = loader.get_template(name).render(template.Context(vals[1])) output = loader.get_template(name).render(template.Context(vals[1]))
except Exception, e: except Exception, e: