I'm the one that proposed this setting be removed.

The settings is used in the following areas:

> ./django/template/backends/django.py:23:
options.setdefault('file_charset', settings.FILE_CHARSET)

I suppose this is its main use case. The Django template engine defaults to
loading files from disk using the encoding specified by FILE_CHARSET. If a
project needs to load templates using a different encoding, it can continue
to do so by specifying an OPTION in the TEMPLATES setting:

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'OPTIONS': {
            'file_charset': 'latin1',
        },
    },
]


> ./django/core/management/commands/makemessages.py:106:        encoding =
settings.FILE_CHARSET if self.command.settings_available else 'utf-8'

The makemessages management command loads files to preprocess using the
encoding specified by FILE_CHARSET.


> ./django/contrib/staticfiles/storage.py:287:                    content =
original_file.read().decode(settings.FILE_CHARSET)

The HashedFilesMixin loads files to preprocess using the encoding specified
by FILE_CHARSET.


> ./django/template/backends/dummy.py:31:                with
open(template_file, encoding=settings.FILE_CHARSET) as fp:

The dummy template backend loads files using the encoding specified by
FILE_CHARSET. This dummy backend is used for internal testing purposes only
and is not a documented or public API. So I think it could safely be
modified without affecting projects or users.


That's it!

I think this setting has the same issue that was identified by
DEFAULT_CONTENT_TYPE. That is, if a projects sets FILE_CHARSET to a
different value, interactions with third-party apps may be problematic. The
third-party app likely encode templates and static files using UTF-8 so the
use cases above may not work properly.

Projects using a different encoding will still have a deprecation period to
see the Django warnings, adjust the setting, and re-encode files. The
removal won't be immediate. If such projects re-encode files to UTF-8
early, the projects will be both backwards and forwards compatible with
current and future Django versions.

FWIW, I was unable to find examples of a changed FILE_CHARSET by searching
GitHub.

Using a different value for FILE_CHARSET is currently untested internally
(although I believe it works as designed).

On Wed, Oct 3, 2018 at 5:03 AM Claude Paroz <cla...@2xlibre.net> wrote:

> We are not talking about general data encodings here, FILE_CHARSET is used
> to read Django text files from disk (template files, static files (css, js)
> or translation catalogs). So the question is mainly about encoding usage in
> text editors.
>
> Claude
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/ba98d239-479f-4b21-b899-8c9b39b921a3%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/ba98d239-479f-4b21-b899-8c9b39b921a3%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADhq2b5Zz9zLOKVZQOJjGNogh%3DYVpAVP0-tWbeTkj3WRr6UrZg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to