[Django] #31598: Broken link in https://docs.gunicorn.org/en/0.17.4/run.html

[Django]

#31598: Broken link in https://docs.gunicorn.org/en/0.17.4/run.html
-+-
   Reporter:  Aroniez|  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Documentation  |Version:  3.0
   Severity:  Normal |   Keywords:  broken link
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  1
  UI/UX:  0  |
-+-
 I found the broken link to this page
 **https://docs.djangoproject.com/en/1.4/howto/deployment/wsgi/** in the
 following subtext

 ''Note
 If you run Django 1.4 or newer, it’s highly recommended to simply run your
 application with the  **WSGI interface** using the gunicorn command.''

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/050.5c2983a007e806196e29f54ca59e4c35%40djangoproject.com.

Re: [Django] #31597: New "Clear all filters" shown always in raw_id_fields popup

[Django]

#31597: New "Clear all filters" shown always in raw_id_fields popup
---+--
 Reporter:  frnhr  |Owner:  frnhr
 Type:  Uncategorized  |   Status:  assigned
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+--
Changes (by frnhr):

 * owner:  nobody => frnhr
 * status:  new => assigned


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.9b90029528326a889ce20c6788c64088%40djangoproject.com.

Re: [Django] #31597: New "Clear all filters" shown always in raw_id_fields popup

[Django]

#31597: New "Clear all filters" shown always in raw_id_fields popup
---+--
 Reporter:  frnhr  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+--
Description changed by frnhr:

Old description:

> The new "Clear all filters" link does not play nice with `raw_id_fields`
> lookup popup window. The new link is shown in the popup regardless of any
> filters being selected or not.
>
> Present in `3.1a1`.
>

> To reproduce:
>
>  * create two models, `ModelA` and `ModelB`
>  * create a Foreign key field on `ModelA` pointing to `ModelB`
>  * create a boolean field on `ModelB`
>
>  * create an admin page for `ModelA`
>  * add the FK field to `raw_id_fields` list
>
>  * create an admin page for `ModelB`
>  * add the boolean field to `list_filter` list
>
>  * open the admin page in a browser
>  * click on the "magnifying class" icon for the `ModelB` field
>
>  * expected:
> * no `X Clear all filters` link
>
>  * actual:
> * yes `X Clear all filters` link
>

> Additionally, clicking the link removes `_to_field` query param, which it
> should not do (`_popup` param is correctly preserved).
>
> [[Image(clearallfiltersrawidfields.png)]]

New description:

 The new "Clear all filters" link does not play nice with `raw_id_fields`
 lookup popup window. The new link is shown in the popup regardless of any
 filters being selected or not.

 Present in `3.1a1`.


 To reproduce:

  * create two models, `ModelA` and `ModelB`
  * create a Foreign key field on `ModelA` pointing to `ModelB`
  * create a boolean field on `ModelB`

  * create an admin page for `ModelA`
  * add the FK field to `raw_id_fields` list

  * create an admin page for `ModelB`
  * add the boolean field to `list_filter` list

  * open the admin page in a browser
  * click on the "magnifying class" icon for the `ModelB` field

  * expected:
 * no `X Clear all filters` link

  * actual:
 * yes `X Clear all filters` link


 Additionally, clicking the link removes `_to_field` query param, which it
 should not do (`_popup` param is correctly preserved).

 [[Image(clearallfiltersrawidfields.jpg)]]

--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.dc6998eb75ed33aca1e0263c57dcf8ef%40djangoproject.com.

Re: [Django] #31597: New "Clear all filters" shown always in raw_id_fields popup

[Django]

#31597: New "Clear all filters" shown always in raw_id_fields popup
---+--
 Reporter:  frnhr  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+--
Changes (by frnhr):

 * Attachment "clearallfiltersrawidfields.jpg" added.


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.a34a836468a0c7ca5a678967618c3f42%40djangoproject.com.

Re: [Django] #31597: New "Clear all filters" shown always in raw_id_fields popup

[Django]

#31597: New "Clear all filters" shown always in raw_id_fields popup
---+--
 Reporter:  frnhr  |Owner:  nobody
 Type:  Uncategorized  |   Status:  new
Component:  contrib.admin  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  1
---+--
Changes (by frnhr):

 * Attachment "clearallfiltersrawidfields.jpg" added.


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.fcd832d479897ab2f76e005526318c4f%40djangoproject.com.

Re: [Django] #31596: ForeignKey.validate() should validate using the base manager.

[Django]

#31596: ForeignKey.validate() should validate using the base manager.
--+--
 Reporter:  Jon Dufresne  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Forms |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Unreviewed
Has patch:  1 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+--
Changes (by Jon Dufresne):

 * has_patch:  0 => 1


Comment:

 https://github.com/django/django/pull/12923

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/067.1508c850b6ed71eb2f6ae000ff1a92b7%40djangoproject.com.

[Django] #31597: New "Clear all filters" shown always in raw_id_fields popup

[Django]

#31597: New "Clear all filters" shown always in raw_id_fields popup
-+
   Reporter:  frnhr  |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  contrib.admin  |Version:  master
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  1  |
-+
 The new "Clear all filters" link does not play nice with `raw_id_fields`
 lookup popup window. The new link is shown in the popup regardless of any
 filters being selected or not.

 Present in `3.1a1`.


 To reproduce:

  * create two models, `ModelA` and `ModelB`
  * create a Foreign key field on `ModelA` pointing to `ModelB`
  * create a boolean field on `ModelB`

  * create an admin page for `ModelA`
  * add the FK field to `raw_id_fields` list

  * create an admin page for `ModelB`
  * add the boolean field to `list_filter` list

  * open the admin page in a browser
  * click on the "magnifying class" icon for the `ModelB` field

  * expected:
 * no `X Clear all filters` link

  * actual:
 * yes `X Clear all filters` link


 Additionally, clicking the link removes `_to_field` query param, which it
 should not do (`_popup` param is correctly preserved).

 [[Image(clearallfiltersrawidfields.png)]]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/048.7591825fb713ca6fae58b91f218a3acd%40djangoproject.com.

[Django] #31596: ForeignKey.validate() should validate using the base manager.

[Django]

#31596: ForeignKey.validate() should validate using the base manager.
+
   Reporter:  Jon Dufresne  |  Owner:  nobody
   Type:  Bug   | Status:  new
  Component:  Forms |Version:  master
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 `ForeignKey.validate()` should validate using the base manager instead of
 the default manager.

 Consider the models:

 {{{
 class ArticleManager(models.Manage):
 def get_queryset(self):
 qs = super().get_queryset()
 return qs.filter(archived=False)

 class Article(models.Model):
 title = models.CharField(max_length=100)
 archived = models.BooleanField(default=False)

 # Don't include archived articles by default.
 objects = ArticleManager()

 class FavoriteAricles(models.Model):
 article = models.ForeignKey(Article, on_delete=models.CASCADE)
 }}}

 In the example, now consider a form that allows users to pick a favorite
 article including archived articles.

 {{{
 class FavoriteAriclesForm(forms.ModelForm):
 class Meta:
 model = FavoriteArticle
 fields = '__all__'

 def __init__(self, *args, **kwargs):
 super().__init__(*args, **kwargs)
 # Use the base manager instead of the default manager to allow
 archived articles.
 self.fields['article'].queryset = Article._base_manager.all()
 }}}

 The above form will never validate as `True` when a user selects an
 archived article. This is because the ForeignKey validation always uses
 `_default_manager` instead of `_base_manager`. The user facing error
 message is "article instance with id 123 does not exist." (quite confusing
 to typical users). The code for this validation is here:

 
https://github.com/django/django/blob/94f63b926fd32d7a7b6e2591ef72aa8f040f25cc/django/db/models/fields/related.py#L917-L919

 The `FavoriteAriclesForm` is specifically designed to use a different
 manager, but the ForeignKey validation makes this difficult.

 In this example scenario, it is not acceptable to change the model's
 default manager as the default should avoid archived articles in other
 typical scenarios.

 Suggested solution: the ForeignKey validation should use the
 `_base_manager` instead which does not include the default filters.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/052.492df47c4248cd263cf0642e9e2d303f%40djangoproject.com.

Re: [Django] #12203: ManyToManyField with through model can't be used in admin

[Django]

#12203: ManyToManyField with through model can't be used in admin
-+-
 Reporter:  David Gouldin|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  M2M, admin,  | Triage Stage:  Accepted
  through, through_fields|
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by frnhr):

 * cc: frnhr (added)


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.bc084fe7cb221379a9687756616fb37f%40djangoproject.com.

Re: [Django] #31595: models.Datefield being localized where it shouldn't

[Django]

#31595: models.Datefield being localized where it shouldn't
-+-
 Reporter:  Akshay Salunke   |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:   |  Version:  2.2
  Internationalization   |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:  DateField, chrome,   | Triage Stage:
  date, format   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Claude Paroz):

 * status:  new => closed
 * resolution:   => invalid


Comment:

 AFAIK Django does not use `type="date"` for its widgets due to browser
 support being too variable. If you set it yourself, you should at least
 force the form fields initialized with `localize=False`. Anyway, this is
 entering support territory.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.941ec63981e33f830fd96442785b55e1%40djangoproject.com.

Re: [Django] #11157: slugify and admin javascript URLify function produce different strings

[Django]

#11157: slugify and admin javascript URLify function produce different strings
--+
 Reporter:  keeperofkeys  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  contrib.admin |  Version:  master
 Severity:  Normal|   Resolution:
 Keywords:  slug  | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Adam (Chainz) Johnson):

 * status:  closed => new
 * severity:   => Normal
 * resolution:  wontfix =>
 * version:  1.1-beta => master
 * easy:   => 0
 * ui_ux:   => 0
 * type:   => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 After discussion on the mailing list (
 https://groups.google.com/forum/#!msg/django-
 developers/9ayU7fTuuAM/tBDLzV5-DQAJ ) in favour of removing the english
 stopwords behaviour from the JavaScript slugify implementation, I'm
 reopening this.

 The discussion originally created ticket #31511 that was closed as a
 duplicate of this one.

 Scott Cranfill and Andy Chosak have a PR that was closed on #31511 that
 needs retargetting against this ticket and current master. (
 https://github.com/django/django/pull/12785 )

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.f205e9d8dfe45529f72358c232feda5d%40djangoproject.com.

Re: [Django] #11157: slugify and admin javascript URLify function produce different strings

[Django]

#11157: slugify and admin javascript URLify function produce different strings
-+-
 Reporter:  keeperofkeys |Owner:  Andy
 Type:   |  Chosak
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:  slug | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Adam (Chainz) Johnson):

 * owner:  nobody => Andy Chosak
 * status:  new => assigned


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/070.7a782faa1109aadea4480ec0b92cbe2a%40djangoproject.com.

Re: [Django] #31595: models.Datefield being localized where it shouldn't

[Django]

#31595: models.Datefield being localized where it shouldn't
-+-
 Reporter:  akshaysalunke13  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  2.2
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  DateField, chrome,   | Triage Stage:
  date, format   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Old description:

> So, I have a DateField in my model and have also set **I18N & L10N** to
> `True`  in settings. When a browser running `en-AU` locale visits the
> website, Django tries to parse the value read from model, using the first
> value in `DATE_INPUT_FORMATS` from /conf.
>
> The bug is when a user in `en-AU` locale visits the website, Django reads
> the Datefield value from model and tries to localize it for `en-AU`
> locale (from `DATE_INPUT_FORMATS` in /conf/en_AU) to this format
> `'%d/%m/%Y'`, but html5 requires the `value` for `` to
> be explicitly in this format: -MM-dd.
> [ref](https://developer.mozilla.org/en-
> US/docs/Web/HTML/Element/input/date) [ref2](https://developer.mozilla.org
> /en-
> US/docs/Web/HTML/Date_and_time_formats#Format_of_a_valid_date_string).
>
> This causes an error in chrome dev console and the HTML date field
> rendered without the date read from the model.[[Image(https://user-
> images.githubusercontent.com/2255284/82113682-326dc080-979b-11ea-8e7f-
> c442f30aae1f.png)]]
> [[Image(https://user-
> images.githubusercontent.com/2255284/82113676-2255e100-979b-11ea-973b-
> 564fdb4a3497.png)]]
>
> **This bug goes away when I disable L10N in settings. I am able to
> reproduce this bug in `en-AU` and `en-GB`**

New description:

 So, I have a DateField in my model and have also set **I18N & L10N** to
 `True`  in settings. When a browser running `en-AU` locale visits the
 website, Django tries to parse the value read from model, using the first
 value in `DATE_INPUT_FORMATS` from /conf.

 The bug is when a user in `en-AU` locale visits the website, Django reads
 the Datefield value from model and tries to localize it for `en-AU` locale
 (from `DATE_INPUT_FORMATS` in /conf/en_AU) to this format `'%d/%m/%Y'`,
 but html5 requires the `value` for `` to be explicitly
 in this format: -MM-dd. [[https://developer.mozilla.org/en-
 US/docs/Web/HTML/Element/input/date| ref1]]
 [[https://developer.mozilla.org/en-
 US/docs/Web/HTML/Date_and_time_formats#Format_of_a_valid_date_string |
 ref2]]

 This causes an error in chrome dev console and the HTML date field
 rendered without the date read from the model.[[Image(https://user-
 images.githubusercontent.com/2255284/82113682-326dc080-979b-11ea-8e7f-
 c442f30aae1f.png)]]
 [[Image(https://user-
 images.githubusercontent.com/2255284/82113676-2255e100-979b-11ea-973b-
 564fdb4a3497.png)]]

 **This bug goes away when I disable L10N in settings. I am able to
 reproduce this bug in `en-AU` and `en-GB`**

--

Comment (by akshaysalunke13):

 Replying to [ticket:31595 akshaysalunke13]:
 > So, I have a DateField in my model and have also set **I18N & L10N** to
 `True`  in settings. When a browser running `en-AU` locale visits the
 website, Django tries to parse the value read from model, using the first
 value in `DATE_INPUT_FORMATS` from /conf.
 >
 > The bug is when a user in `en-AU` locale visits the website, Django
 reads the Datefield value from model and tries to localize it for `en-AU`
 locale (from `DATE_INPUT_FORMATS` in /conf/en_AU) to this format
 `'%d/%m/%Y'`, but html5 requires the `value` for `` to
 be explicitly in this format: -MM-dd.
 [ref](https://developer.mozilla.org/en-
 US/docs/Web/HTML/Element/input/date) [ref2](https://developer.mozilla.org
 /en-US/docs/Web/HTML/Date_and_time_formats#Format_of_a_valid_date_string).
 >
 > This causes an error in chrome dev console and the HTML date field
 rendered without the date read from the model.[[Image(https://user-
 images.githubusercontent.com/2255284/82113682-326dc080-979b-11ea-8e7f-
 c442f30aae1f.png)]]
 > [[Image(https://user-
 images.githubusercontent.com/2255284/82113676-2255e100-979b-11ea-973b-
 564fdb4a3497.png)]]
 >
 > **This bug goes away when I disable L10N in settings. I am able to
 reproduce this bug in `en-AU` and `en-GB`**

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and s

Re: [Django] #31595: models.Datefield being localized where it shouldn't

[Django]

#31595: models.Datefield being localized where it shouldn't
-+-
 Reporter:  akshaysalunke13  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  2.2
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  DateField, chrome,   | Triage Stage:
  date, format   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by akshaysalunke13:

Old description:

> So, I have a DateField in my model and have also set I18N & L10N to
> `True`  in settings. When a browser running `en-AU` locale visits the
> website, Django tries to parse the value read from model, using the first
> value in `DATE_INPUT_FORMATS` from /conf.
>
> The bug is when a user in `en-AU` locale visits the website, Django reads
> the Datefield value from model and tries to localize it for `en-AU`
> locale (from `DATE_INPUT_FORMATS` in /conf/en_AU) to this format
> `'%d/%m/%Y'`, but html5 requires the `value` for `` to
> be explicitly in this format: -MM-dd.
> [ref](https://developer.mozilla.org/en-
> US/docs/Web/HTML/Element/input/date) [ref2](https://developer.mozilla.org
> /en-
> US/docs/Web/HTML/Date_and_time_formats#Format_of_a_valid_date_string).
>
> This causes an error in chrome dev console and the HTML date field
> rendered without the date read from the model.[[Image(https://user-
> images.githubusercontent.com/2255284/82113682-326dc080-979b-11ea-8e7f-
> c442f30aae1f.png)]]
> [[Image(https://user-
> images.githubusercontent.com/2255284/82113676-2255e100-979b-11ea-973b-
> 564fdb4a3497.png)]]
>
> **This bug goes away when I disable L10N in settings. I am able to
> reproduce this bug in `en-AU` and `en-GB`**

New description:

 So, I have a DateField in my model and have also set **I18N & L10N** to
 `True`  in settings. When a browser running `en-AU` locale visits the
 website, Django tries to parse the value read from model, using the first
 value in `DATE_INPUT_FORMATS` from /conf.

 The bug is when a user in `en-AU` locale visits the website, Django reads
 the Datefield value from model and tries to localize it for `en-AU` locale
 (from `DATE_INPUT_FORMATS` in /conf/en_AU) to this format `'%d/%m/%Y'`,
 but html5 requires the `value` for `` to be explicitly
 in this format: -MM-dd. [ref](https://developer.mozilla.org/en-
 US/docs/Web/HTML/Element/input/date) [ref2](https://developer.mozilla.org
 /en-US/docs/Web/HTML/Date_and_time_formats#Format_of_a_valid_date_string).

 This causes an error in chrome dev console and the HTML date field
 rendered without the date read from the model.[[Image(https://user-
 images.githubusercontent.com/2255284/82113682-326dc080-979b-11ea-8e7f-
 c442f30aae1f.png)]]
 [[Image(https://user-
 images.githubusercontent.com/2255284/82113676-2255e100-979b-11ea-973b-
 564fdb4a3497.png)]]

 **This bug goes away when I disable L10N in settings. I am able to
 reproduce this bug in `en-AU` and `en-GB`**

--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.3027794c75a2d8e823ba0b91fac292e8%40djangoproject.com.

Re: [Django] #31595: models.Datefield being localized where it shouldn't

[Django]

#31595: models.Datefield being localized where it shouldn't
-+-
 Reporter:  akshaysalunke13  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  2.2
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  DateField, chrome,   | Triage Stage:
  date, format   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by akshaysalunke13):

 * Attachment "chrome-console-error.png" added.

 Error in chrome dev console.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.e388bd2f14bf50385b31e7b7bd4974b6%40djangoproject.com.

Re: [Django] #31595: models.Datefield being localized where it shouldn't

[Django]

#31595: models.Datefield being localized where it shouldn't
-+-
 Reporter:  akshaysalunke13  |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:   |  Version:  2.2
  Internationalization   |
 Severity:  Normal   |   Resolution:
 Keywords:  DateField, chrome,   | Triage Stage:
  date, format   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by akshaysalunke13):

 * Attachment "datepicker-chrome.png" added.

 This is how date picker looks in chrome when locale is en-AU even when
 this field has an initials value.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/073.3ac1fc011f2365301238255979f81a3c%40djangoproject.com.

[Django] #31595: models.Datefield being localized where it shouldn't

[Django]

#31595: models.Datefield being localized where it shouldn't
-+-
   Reporter: |  Owner:  nobody
  akshaysalunke13|
   Type:  Bug| Status:  new
  Component: |Version:  2.2
  Internationalization   |   Keywords:  DateField, chrome,
   Severity:  Normal |  date, format
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 So, I have a DateField in my model and have also set I18N & L10N to `True`
 in settings. When a browser running `en-AU` locale visits the website,
 Django tries to parse the value read from model, using the first value in
 `DATE_INPUT_FORMATS` from /conf.

 The bug is when a user in `en-AU` locale visits the website, Django reads
 the Datefield value from model and tries to localize it for `en-AU` locale
 (from `DATE_INPUT_FORMATS` in /conf/en_AU) to this format `'%d/%m/%Y'`,
 but html5 requires the `value` for `` to be explicitly
 in this format: -MM-dd. [ref](https://developer.mozilla.org/en-
 US/docs/Web/HTML/Element/input/date) [ref2](https://developer.mozilla.org
 /en-US/docs/Web/HTML/Date_and_time_formats#Format_of_a_valid_date_string).

 This causes an error in chrome dev console and the HTML date field
 rendered without the date read from the model.[[Image(https://user-
 images.githubusercontent.com/2255284/82113682-326dc080-979b-11ea-8e7f-
 c442f30aae1f.png)]]
 [[Image(https://user-
 images.githubusercontent.com/2255284/82113676-2255e100-979b-11ea-973b-
 564fdb4a3497.png)]]

 **This bug goes away when I disable L10N in settings. I am able to
 reproduce this bug in `en-AU` and `en-GB`**

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/058.bc8458ca9339e97ffe05dca2d86c2ed3%40djangoproject.com.