(Circa end of 2021) Localization issues with input type=date?

[Carlton Gibson]

Hi all. 

There's a PR to add examples using `` for 
`forms.DateInput`. 
https://github.com/django/django/pull/14905

Support for HTML5 input types was added a long time back now in #16630 
.
Back then there were various issues with localisation when **not** using 
type=text. 
See https://code.djangoproject.com/ticket/16630#comment:11 and following 
discussion. 
The original mailing list thread is here 

.

The goal is to say something succinct but accurate that covers both sides 
of "Why the default is type=text" and "What you need to consider using 
type=date". 

Can we solicit some input (🥁) on what issues folks hit? — specifically for 
DateInput the concern was the required date format (I think). 

It may well be that things have changed since 2012? (If so we might revisit 
#21470 .)

Thanks. 
Carlton


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/16d05604-4068-4423-9ac4-f8f520d44a42n%40googlegroups.com.

Re: (Circa end of 2021) Localization issues with input type=date?

[Tom Carrick]

Hi,

It's true that the value is required to be in -MM-DD format, but in
modern browsers (which I think is what we claim to support now, right?) it
will show in the user's localised format. I checked this in Firefox,
Chrome, Edge, and they all look good to me - they come with both a date
picker, and allow you to enter the date in your local format. So I think
the time has come where this might be a beneficial change (for #21470).
However, Firefox is lacking a picker for 
until the next version, though presumably that will be released before any
change here would make it in.

Probably the problem here is that if we make this the default, we will
break people's code who are not explicitly rendering their forms.

It also might be nice to use these in the admin and remove our own date
picker code, if it doesn't pose any problems.

I realise this isn't actually an answer to your initial question, though.

Cheers,
Tom

On Tue, 28 Sept 2021 at 11:16, Carlton Gibson 
wrote:

> Hi all.
>
> There's a PR to add examples using `` for
> `forms.DateInput`.
> https://github.com/django/django/pull/14905
>
> Support for HTML5 input types was added a long time back now in #16630
> .
> Back then there were various issues with localisation when **not** using
> type=text.
> See https://code.djangoproject.com/ticket/16630#comment:11 and following
> discussion.
> The original mailing list thread is here
> 
> .
>
> The goal is to say something succinct but accurate that covers both sides
> of "Why the default is type=text" and "What you need to consider using
> type=date".
>
> Can we solicit some input (🥁) on what issues folks hit? — specifically
> for DateInput the concern was the required date format (I think).
>
> It may well be that things have changed since 2012? (If so we might
> revisit #21470 .)
>
> Thanks.
> Carlton
>
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/16d05604-4068-4423-9ac4-f8f520d44a42n%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAHoz%3DMYCeFm-CHosr6TE%2BmuO3%2BgY-B97KmskozNX5rfYi4GMkA%40mail.gmail.com.

Re: (Circa end of 2021) Localization issues with input type=date?

[אורי]

Hi,

I'm using a JS datepicker on https://en.speedy.net/ since 2017 and it
works fine. It works both in English and Hebrew (which is RTL). I never
found a need to use anything native to Django or browsers since the JS
datepicker I'm using is great. I can customize the visible date format in
each language and the names of the months. In the background it uses a
hidden input in -MM-DD format.


אורי
u...@speedy.net


On Tue, Sep 28, 2021 at 12:16 PM Carlton Gibson 
wrote:

> Hi all.
>
> There's a PR to add examples using `` for
> `forms.DateInput`.
> https://github.com/django/django/pull/14905
>
> Support for HTML5 input types was added a long time back now in #16630
> .
> Back then there were various issues with localisation when **not** using
> type=text.
> See https://code.djangoproject.com/ticket/16630#comment:11 and following
> discussion.
> The original mailing list thread is here
> 
> .
>
> The goal is to say something succinct but accurate that covers both sides
> of "Why the default is type=text" and "What you need to consider using
> type=date".
>
> Can we solicit some input (🥁) on what issues folks hit? — specifically
> for DateInput the concern was the required date format (I think).
>
> It may well be that things have changed since 2012? (If so we might
> revisit #21470 .)
>
> Thanks.
> Carlton
>
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/16d05604-4068-4423-9ac4-f8f520d44a42n%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CABD5YeE%3Du-43CHakj-tskbVZztrfbmLti4vEn5kmp639SdF4BA%40mail.gmail.com.

optionally show all models in admin per default in DEBUG

[Christian González]

Hi again.

Maybe this has been discussed before (please tell me).

In each and every Django project I start, I need the Django Admin during 
development to create some model data for testing.


And each and every time  I wonder why I have to add the same boilerplate 
code for every single model in every app.


So in most projects, I start with a generic way of adding all models to 
admin.py programmatically.


and after a few iterations, I thought I'll ask you if that wasn't a 
helpful default to add to Django itself.


* I know that there are ModelAdmins, in case you want to sort it out 
differently
* I know that there are edge cases and abstract models that shouldn't be 
listed


So what if Django (admin) would add models to the admin view, if

* DEBUG==True,
* maybe another attr is present, like settings.AUTO_ADMIN_MODELS
* all admin.py files are already parsed and manually added models are 
included, with their special ModelAdmins


like:

# first parse all apps' admin.py

if settings.DEBUG:
    # all other models
    models = apps.get_models()

    for model in models:
    try:
    if not model._meta.abstract:
    admin.site.register(model)
    except admin.sites.AlreadyRegistered:
    pass


It would help getting started with Django more quickly.

--
Dr. Christian González
https://nerdocs.at

--
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d3aba97f-42e5-72f8-5cb2-20381c1358fa%40nerdocs.at.