mirror of
https://github.com/django/django.git
synced 2025-08-04 19:08:28 +00:00
Removed versionadded/changed annotations for 2.1.
This commit is contained in:
parent
eb0ce6fa36
commit
ec7e179aeb
25 changed files with 0 additions and 208 deletions
|
@ -1778,10 +1778,6 @@ language choice in the user's session. It also saves the language choice in a
|
|||
cookie that is named ``django_language`` by default. (The name can be changed
|
||||
through the :setting:`LANGUAGE_COOKIE_NAME` setting.)
|
||||
|
||||
.. versionchanged:: 2.1
|
||||
|
||||
In older versions, the cookie is only set if session support isn't enabled.
|
||||
|
||||
After setting the language choice, Django looks for a ``next`` parameter in the
|
||||
``POST`` or ``GET`` data. If that is found and Django considers it to be a safe
|
||||
URL (i.e. it doesn't point to a different host and uses a safe scheme), a
|
||||
|
@ -2098,10 +2094,6 @@ etc. Untranslated strings for territorial language variants use the translations
|
|||
of the generic language. For example, untranslated ``pt_BR`` strings use ``pt``
|
||||
translations.
|
||||
|
||||
.. versionchanged:: 2.1
|
||||
|
||||
Fallback to the generic language as described above was added.
|
||||
|
||||
This way, you can write applications that include their own translations, and
|
||||
you can override base translations in your project. Or, you can just build
|
||||
a big project out of several apps and put all translations into one big common
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue