Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed #35306 -- Updated 5.0 Docs #18028

Open
wants to merge 7 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from 4 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
15 changes: 8 additions & 7 deletions docs/ref/settings.txt
Original file line number Diff line number Diff line change
Expand Up @@ -1838,21 +1838,22 @@ A list of IP addresses, as strings, that:

Default: ``'en-us'``

A string representing the language code for this installation. This should be in
standard :term:`language ID format <language code>`. For example, U.S. English
is ``"en-us"``. See also the `list of language identifiers`_ and
:doc:`/topics/i18n/index`.

:setting:`USE_I18N` must be active for this setting to have any effect.
A string representing the fallback language code for this installation.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we can add fallback here. The paragraph below explains in which case it is used as a fallback language, and when it is the language served to all users.

This should be in standard :term:`language ID format <language code>`.
For example, U.S. English is ``"en-us"``. See also the
`list of language identifiers`_ and :doc:`/topics/i18n/index`.

It serves two purposes:
It serves three purposes:

* If the locale middleware isn't in use, it decides which translation is served
to all users.
* If the locale middleware is active, it provides a fallback language in case the
user's preferred language can't be determined or is not supported by the
website. It also provides the fallback translation when a translation for a
given literal doesn't exist for the user's preferred language.
* If localization is explicitly disabled via the :tfilter:`localize` and
:tfilter:`unlocalize` template filters or tags. see
:ref:`controlling localization in templates <topic-l10n-templates>`.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sentence is not complete. However, as a non-native speaker, I'll happily defer choosing a better formulation to someone else.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, "see" needs to be capitalized and it would be good to end with "for [insert something]".
You can just say "for more details" but you might want to be more specific like "for further explanation on [insert something]."
Rough example:

See :ref:`controlling localization in templates <topic-l10n-templates>` for more details.

See :ref:`how-django-discovers-language-preference` for more details.

Expand Down
3 changes: 3 additions & 0 deletions docs/topics/i18n/formatting.txt
Original file line number Diff line number Diff line change
Expand Up @@ -60,6 +60,9 @@ to be machine-readable, you will always want unlocalized values. You
may also want to use localization in selected templates, rather than
using localization everywhere.

The format used is the one from the settings and under normal circumstances
the locale dictated format has a higher precedence and will be applied instead.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What format? Which settings? Sorry, but I don't think this adds much clarity to these docs.

Maybe something like (once again I'm not a skilled English writer):
When localization is disabled through one of the tag or filter described below, the localization formats used are taken from the general formatting settings (list of settings here?).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @claudep , thanks for your review and response on this, Just for clarity, is it okay to pass a reference to the globalization settings as the general formatting settings instead of listing them.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good idea for this link! Now that I see that list, maybe it would be nice to distinguish in that list the settings that may overriding by locale formats, and those that don't, and then suggest (maybe in a different PR) separating that list in two sub-lists. Then we would have a perfect section to link to in this PR.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It sounds like we still want to do this, it can be a separate commit or another PR 👍


To allow for fine control over the use of localization, Django
provides the ``l10n`` template library that contains the following
tags and filters.
Expand Down