> You can simply do that by including a gettext_noop('your custom string')
> line anywhere in your code (or in a specific file you create for that
> purpose).
>
>
This is an ugly workaround. Makemessages has other issue - it grabs
messages from external eggs/packages, which are found in
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
Hello.
There is a huge issue with content types framework. The data is loaded
after every migration (post_migrate signal) automatically, and this
approach is against db data consistency.
The biggest problem is with data migrations, which are applied at the first
time (on clean database). Any
]
>
> Wouldn't a workaround be to call create_contenttypes() in a RunPython in
> your app's migration before inserting the data which depends on the content
> types?
>
>
Thanks, but as a workaround you can do almost everything. My post is about
proposal of fixing the issue.
BTW: RunPython() is
Thanks for the input everyone.
So Jon, are you basically saying that Vasili's concern shouldn't come up?
(That the whole "SQL data files" bit is misleading...?)
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)"
Wouldn't a workaround be to call create_contenttypes() in a RunPython in
your app's migration before inserting the data which depends on the content
types?
On Wed, 3 Oct 2018 at 12:01, Marcin Nowak wrote:
> Hello.
>
> There is a huge issue with content types framework. The data is loaded
>
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
Jon's logic seems right to me. I find the lack of tests disturbing, and I
wouldn't be surprised if there were other places where django loaded files
from disk without using FILE_CHARSET when a user of that setting would
expect it to be.
On Wed, 3 Oct 2018 at 15:55, Carlton Gibson
wrote:
>
> So Jon, are you basically saying that Vasili's concern shouldn't come up?
Yeah, I think it shouldn't come up. But I'm not sure I fully understand
Vasili's concern . Maybe if it was more specific with more details, I could
better understand it.
Django's documentation states:
Thanks for the follow-up Jon.
I'll let Vasili follow-up on his use-case if possible/relevant.
TBH I'm not at all sure about the SQL data files bit, which is in part why
I asked here.
(Encoding issues!)
> Maybe that sentence should be rephrased to "template
files, static files, and
On Sunday, 30 September 2018 06:51:41 UTC+2, James Bennett wrote:
>
> Does anyone else have feedback on this? I'd like to push it forward.
>
I don't know if this would fly but, given that pre-notification is mainly
thought of for large-scale ("enterprise"?) deployments that can't
realistically
> FILE_CHARSET (default:'utf-8')
> The character encoding used to decode any files read from disk. This
includes template files and initial SQL data files.
Is there anywhere where this isn't UTF-8? (Or can't be decreed to be so?)
Jon has a suggestion to remove it:
Ticket:
Timezone handling in the Django admin is quite confusing for users when the
users are in multiple timezones, because everything in the admin site
operates in the server's time.
Assuming USE_TZ=True, TIME_ZONE='UTC', USE_I18N, USE_L10N, when viewing a
datetime field, users see the UTC time,
Can: yes. Should: no.
I would be really saddened to see companies being able to buy security by
throwing money at us. That makes us look like we can be bought. And that sends
the wrong signal, from my perspective. Timely security updates should be
available to everyone.
Should enterprises
On Wed, Oct 3, 2018 at 2:18 AM Markus Holtermann
wrote:
> Can: yes. Should: no.
Yeah, the idea's been proposed a couple times, and my stance on it is that
I'd quit not just the security team, but everything Django-related, if we
did that. Pay-to-play for security is not acceptable, period.
--
Yes. That all sounds reasonable.
We DO timely releases to all (and we pre-announce so people know they’re
coming).
It’s just this extra category of people who get the patch separately, early.
There’s extra overhead in that. And it removes one motivation to update.
I’m kind of inclined to
Some Russian companies still store their old data (in databases and/or
files) in KOI8-R. I'm not sure how many of them may be using Django, but I
personally worked for a company in 2014-2015, that maintained a huge
database of articles stored in KOI8-R. I can assume that, similarly, KOI8-U
may
17 matches
Mail list logo
