I think for the admin fonts, we put those in a separate css file:
fonts.css, so you could easily disable them by replacing that file with a
blank file. We could probably do the same thing with a responsive.css file.
(Though if we do give the option to switch, do we now need to support and
test
IMO this doesn't change the argument that it would be best to default to
the higher number of iterations (i.e., 100k or higher, given some time as
passed since 2013), while noting in the documentation that individual
projects have the ability to reduce it if need be (though perhaps
recommending
According to ticket #23908 [0],
By using the setting:
DEFAULT_CONTENT_TYPE = "application/xhtml+xml"
The admin site no longer renders correctly.
Do you think we should try to fix this by having all the admin responses
specify content_type="text/html"? That requires a lot of changes [1] --
...in the meantime. I've created a proof of concept repo
(https://github.com/benzkji/djangocms-untranslated-placeholders), that uses
the code from my pull request. some things I learned/discovered:
- it works already quite well
- untranslated plugins are still added with a language_code.
On Monday, January 9, 2017 at 2:43:00 PM UTC-5, Дмитрий Симонов wrote:
>
> Ok. Here is my example with multiline annotations.
>
> https://github.com/a1fred/django-template-type-annotations
>
> What do you think?
>
It should probably avoid parsing of the main body, I don't believe that to
be
Django doesn't depend on flake8, so it can't be used during migration
generation. Otherwise, I think aliasing the conflicting modules (6) is
indeed a better way.
The problem came about on #django IRC channel because someone named an app
"settings", presumably to store some configuration.
--
