date:20240125

Re: [Django] #29280: Add a database OPTIONS to specify the transaction mode one SQLite.

2024-01-25 Thread Django

#29280: Add a database OPTIONS to specify the transaction mode one SQLite.
-+-
 Reporter:  Ove Kåven|Owner:  Anže
 |  Pečar
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite, databases| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  0 => 1

-- 
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/0107018d44ae5ca0-dda854b5-6535-4acb-85c2-dcb12e1ed80e-00%40eu-central-1.amazonses.com.

Re: [Django] #34533: OuterRef not resolved as part oh ORDER BY clause

2024-01-25 Thread Django

#34533: OuterRef not resolved as part oh ORDER BY clause
-+-
 Reporter:  REGNIER Guillaume|Owner:  (none)
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  OuterRef, OrderBy| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Shafiya Adzhani):

 * owner:  Shafiya Adzhani => (none)
 * status:  assigned => new

-- 
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/0107018d443f00f0-b0188a2e-bb6a-42e6-8396-f83d9c2bafb9-00%40eu-central-1.amazonses.com.

Re: [Django] #34533: OuterRef not resolved as part oh ORDER BY clause

2024-01-25 Thread Django

#34533: OuterRef not resolved as part oh ORDER BY clause
-+-
 Reporter:  REGNIER Guillaume|Owner:  Shafiya
 |  Adzhani
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.2
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  OuterRef, OrderBy| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Shafiya Adzhani):

 Replying to [comment:10 Simon Charette]:
 > The hard part is here is likely due to two factor
 >
 > 1. `OuterRef` resolving is quite finicky and depends on a specific chain
 of resolving during query composition (subquery is resolved and then the
 outer query is)
 > 2. `order_by` members are unfortunately not resolved at query
 composition time (when `QuerySet.order_by` is called) but
 
[https://github.com/django/django/blob/12ffcfc350a19bbfbc203126a9b6c84b5e0d0ba2/django/db/models/sql/compiler.py#L466
 at query compilation time].
 >
 > The reason for 2. is that `QuerySet.order_by` calls are not additive but
 destructive and that the query composition logic doesn't support a generic
 way of eliding joins that we previously created for some operations.
 >
 > For example, say that you have a query that does `qs =
 Book.objects.order_by("author__name")`. If the order by clause is
 immediately resolved then a `JOIN` to `author` must be created. If the
 same query has then its ordering changed to `qs.order_by("title")` then
 we'd want to clear the join to `author` as it's no longer necessary.
 >
 > In order to avoid implementing the logic to ''unreference'' relations
 the `order_by` method deferred the resolving to the very end of query
 compilation which is a different path than the ''normal'' resolving taking
 place in additive methods such as `annotate` and `filter`.
 >
 > I suspect this ticket will be hard to solve without tackling the large
 problem of compile time resolving of `order_by`.

 Thank you for the pointer! Since this ticket is complicated, I'll leave it
 to someone who is interested in solving this problem.
-- 
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/0107018d443ecffa-c80bf94c-2a7c-4a24-ae70-c01f97da41c0-00%40eu-central-1.amazonses.com.

Re: [Django] #33037: TruncDay error when using offset timezones on MySQL, SQLite, and Oracle.

2024-01-25 Thread Django

#33037: TruncDay error when using offset timezones on MySQL, SQLite, and Oracle.
-+-
 Reporter:  Alan |Owner:  Shafiya
 |  Adzhani
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  mysql truncdate  | Triage Stage:  Accepted
  timezone   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Shafiya Adzhani):

 * owner:  nobody => Shafiya Adzhani
 * 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/0107018d443cf115-d86f2c5d-1207-4a62-a8e1-61990798e59e-00%40eu-central-1.amazonses.com.

Re: [Django] #33037: TruncDay error when using offset timezones on MySQL, SQLite, and Oracle.

2024-01-25 Thread Django

#33037: TruncDay error when using offset timezones on MySQL, SQLite, and Oracle.
-+-
 Reporter:  Alan |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  mysql truncdate  | Triage Stage:  Accepted
  timezone   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Shafiya Adzhani):

 This ticket is still open, right? I will try to understand it and create
 the patch.
-- 
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/0107018d443be87f-ad3b79ec-9055-46c8-b12b-98982274d914-00%40eu-central-1.amazonses.com.

Re: [Django] #35145: Django admin’s dark theme should set color-scheme property for vanilla HTML components

2024-01-25 Thread Django

#35145: Django admin’s dark theme should set color-scheme property for vanilla 
HTML
components
-+-
 Reporter:  Thibaud Colas|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  5.0
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility,   | Triage Stage:  Accepted
  color contrast, dark mode, dark|
  theme  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Mariusz Felisiak):

 * stage:  Unreviewed => Accepted

-- 
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/0107018d4406f6fc-73f1d5ff-470d-42d0-9dc7-cca8d2704ece-00%40eu-central-1.amazonses.com.

Re: [Django] #35141: CACHE_MIDDLEWARE_SECONDS can be set to a float but has to be an int

2024-01-25 Thread Django

#35141: CACHE_MIDDLEWARE_SECONDS can be set to a float but has to be an int
-+-
 Reporter:  Alexander Lazarević  |Owner:  Alexander
 Type:   |  Lazarević
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Cache system)  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Alexander Lazarević):

 > I'm not sure we want to go down the path of casting every integer
 setting?

 Maybe this could be part of the system checks? Here as an example only for
 one setting, but could be extended to more settings as well.

 {{{
 @register(Tags.files)
 def check_settings_types(app_configs, **kwargs):
 setting = getattr(settings, "CACHE_MIDDLEWARE_SECONDS", None)
 if setting and not isinstance(setting, int):
 return [
 Error(
 "The CACHE_MIDDLEWARE_SECONDS setting should be an
 integer.",
 id="files.E002",
 )
 ]
 return []
 }}}
-- 
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/0107018d44028299-4eca6e88-cd53-4250-8b6c-2534c58c0bb8-00%40eu-central-1.amazonses.com.

Re: [Django] #35141: CACHE_MIDDLEWARE_SECONDS can be set to a float but has to be an int

2024-01-25 Thread Django

#35141: CACHE_MIDDLEWARE_SECONDS can be set to a float but has to be an int
-+-
 Reporter:  Alexander Lazarević  |Owner:  Alexander
 Type:   |  Lazarević
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Cache system)  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Alexander Lazarević):

 * needs_docs:  1 => 0
 * needs_tests:  1 => 0

Comment:

 I changed the PR accordingly
-- 
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/0107018d43b91100-44ab3b4f-a088-40ee-b073-52cdd93f8e35-00%40eu-central-1.amazonses.com.

Re: [Django] #35141: CACHE_MIDDLEWARE_SECONDS can be set to a float but has to be an int

2024-01-25 Thread Django

#35141: CACHE_MIDDLEWARE_SECONDS can be set to a float but has to be an int
-+-
Reporter: Alexander Lazarević |Owner: Alexander
Type: | Lazarević
Cleanup/optimization | Status: assigned
Component: Core (Cache system) | Version: dev
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1| Needs documentation: 1
Needs tests: 1| Patch needs improvement: 0
Easy pickings: 0|UI/UX: 0
-+-
Comment (by Alexander Lazarević):

Ok in #35041 it's been said that

> ... however we cannot add type checks for all settings. It's documented
as integer and Django crashes when you use it incorrectly, so it's hard to
miss.

Well currently a float for CACHE_MIDDLEWARE_SECONDS will just work, but
produce the wrong value for max_age, which is easy to miss.

But looking forward I have a draft PR for #27225 that will make Django
crash, when CACHE_MIDDLEWARE_SECONDS is a float. So this would be a harsh
indicator that the setting for CACHE_MIDDLEWARE_SECONDS is wrong.

'''With that I'm suggesting I change the PR for this ticket to "just" fix
the comment and the setting in the testcase? What do you think?'''

Regardless of that, maybe two more thoughts:

> Certainly, but I wonder if it's Django's responsibility (and any third-
party code that uses the setting) to silently correct such a mistake.

In this case I would rather want Django sillently do the right thing than
silently do the wrong thing.

> I'm not sure we want to go down the path of casting every integer
setting?

I think we shouldn't make the perfect (type checking every setting) the
enemy of the good (fixing one particular problem with one setting). In
general.
--
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/0107018d43a177a1-7a144c68-36b9-4e06-bbbe-f905ccf7fb5c-00%40eu-central-1.amazonses.com.

Re: [Django] #35145: Django admin’s dark theme should set color-scheme property for vanilla HTML components

2024-01-25 Thread Django

#35145: Django admin’s dark theme should set color-scheme property for vanilla 
HTML
components
-+-
 Reporter:  Thibaud Colas|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  5.0
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility,   | Triage Stage:
  color contrast, dark mode, dark|  Unreviewed
  theme  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Description changed by Thibaud Colas:

Old description:

> The Django admin uses unstyled vanilla HTML widgets for a few scenarios.
> Currently in the dark theme those elements are displayed with the
> browser’s default "light" UI – it would better if we instructed the
> browser to use their dark variant with the CSS `color-scheme` property.
>
> Here’s an example, where [https://developer.mozilla.org/en-
> US/docs/Web/CSS/color-scheme color-scheme] affects the search field’s
> clear button color and checkboxes, before/after:
>

>
> - For the clear button it’s almost invisible without this so is a clear
> accessibility issue / WCAG contrast fail
> - For the checkboxes it just looks better.
>
> This also affects file inputs, multi-select widgets, scrollbars, and I’m
> sure other parts of the UI.
>
> ---
>
> My suggested solution would be to add `color-scheme: dark` at the root
> level when in dark mode, but it might be worth researching a bit to make
> sure we use the property as well as possible.

New description:

 The Django admin uses unstyled vanilla HTML widgets for a few scenarios.
 Currently in the dark theme those elements are displayed with the
 browser’s default "light" UI – it would better if we instructed the
 browser to use their dark variant with the CSS `color-scheme` property.

 Here’s an example, where [https://developer.mozilla.org/en-US/docs/Web/CSS
 /color-scheme color-scheme] affects the search field’s clear button color
 and checkboxes, before/after:

 [[Image(https://code.djangoproject.com/raw-attachment/ticket/35145/color-
 scheme-django.gif)]]

 - For the clear button it’s almost invisible without this so is a clear
 accessibility issue / WCAG contrast fail
 - For the checkboxes it just looks better.

 This also affects file inputs, multi-select widgets, scrollbars, and I’m
 sure other parts of the UI.

 ---

 My suggested solution would be to add `color-scheme: dark` at the root
 level when in dark mode, but it might be worth researching a bit to make
 sure we use the property as well as possible.

--
-- 
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/0107018d42b1785e-c9f7f901-4f30-444b-a00f-c87e42fe375b-00%40eu-central-1.amazonses.com.

Re: [Django] #35145: Django admin’s dark theme should set color-scheme property for vanilla HTML components

2024-01-25 Thread Django

#35145: Django admin’s dark theme should set color-scheme property for vanilla 
HTML
components
-+-
 Reporter:  Thibaud Colas|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  5.0
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility,   | Triage Stage:
  color contrast, dark mode, dark|  Unreviewed
  theme  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Comment (by Thibaud Colas):

 cc @erosselli who was interested in working on this (but please wait for
 it to be approved)
-- 
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/0107018d42b0f8f7-02a72044-d4b9-49ed-a17a-265d08361601-00%40eu-central-1.amazonses.com.

Re: [Django] #35145: Django admin’s dark theme should set color-scheme property for vanilla HTML components

2024-01-25 Thread Django

#35145: Django admin’s dark theme should set color-scheme property for vanilla 
HTML
components
-+-
 Reporter:  Thibaud Colas|Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  contrib.admin|  Version:  5.0
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility,   | Triage Stage:
  color contrast, dark mode, dark|  Unreviewed
  theme  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Changes (by Thibaud Colas):

 * Attachment "color-scheme-django.gif" added.

 Recording of color-scheme set to dark and unset in Django admin
-- 
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/0107018d42ad01d7-3c697c64-6c4d-438d-bb37-2702cc0848fe-00%40eu-central-1.amazonses.com.

[Django] #35145: Django admin’s dark theme should set color-scheme property for vanilla HTML components

2024-01-25 Thread Django

#35145: Django admin’s dark theme should set color-scheme property for vanilla 
HTML
components
-+-
   Reporter:  Thibaud|  Owner:  nobody
  Colas  |
   Type:  Bug| Status:  new
  Component: |Version:  5.0
  contrib.admin  |   Keywords:  accessibility,
   Severity:  Normal |  color contrast, dark mode, dark
   Triage Stage: |  theme
  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  1  |
-+-
 The Django admin uses unstyled vanilla HTML widgets for a few scenarios.
 Currently in the dark theme those elements are displayed with the
 browser’s default "light" UI – it would better if we instructed the
 browser to use their dark variant with the CSS `color-scheme` property.

 Here’s an example, where [https://developer.mozilla.org/en-US/docs/Web/CSS
 /color-scheme color-scheme] affects the search field’s clear button color
 and checkboxes, before/after:



 - For the clear button it’s almost invisible without this so is a clear
 accessibility issue / WCAG contrast fail
 - For the checkboxes it just looks better.

 This also affects file inputs, multi-select widgets, scrollbars, and I’m
 sure other parts of the UI.

 ---

 My suggested solution would be to add `color-scheme: dark` at the root
 level when in dark mode, but it might be worth researching a bit to make
 sure we use the property as well as possible.
-- 
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/0107018d42ac5252-c0b608e6-1bf1-486e-bd99-4e2be242ab89-00%40eu-central-1.amazonses.com.

Re: [Django] #35137: Collapsible error container elements do not indicate that they are interactive

2024-01-25 Thread Django

#35137: Collapsible error container elements do not indicate that they are
interactive
--+
 Reporter:  Denis Anuschewski |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Error reporting   |  Version:  dev
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  1
--+
Comment (by Denis Anuschewski):

 Another suggestion for a simple solution:

 Adapt the icon for the collapsible link "Local vars" just under the gray
 error box (placed on the left of the line number just like Thibaud
 mentioned).
 Plus implement a thin border to let the box stand out more.
-- 
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/0107018d41a58a50-730e1b2c-db4f-43f8-b450-fd2a7a24c51f-00%40eu-central-1.amazonses.com.

Re: [Django] #35137: Collapsible error container elements do not indicate that they are interactive

2024-01-25 Thread Django

#35137: Collapsible error container elements do not indicate that they are
interactive
--+
Reporter: Denis Anuschewski |Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Error reporting | Version: dev
Severity: Normal| Resolution:
Keywords:| Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 |UI/UX: 1
--+
Comment (by Thibaud Colas):

Note there are three separate issues here:

1. Bug: the current implementation is unusable for keyboard and voice
control users due to adding interactivity to list item elements.
2. Somewhere between a bug and a usability fail: placing the "this is
collapsible" signifier all the way to the right means it’s more or less
impossible to spot for users of screen magnification
3. And usability issue – it’s hard to understand this is interactive.

I’d recommend fixing them all at once by introducing a "toggle" button to
the left of the line number, so we can solve the issue at hand without
reinventing the current designs. That button will be focusable and can
either have a visible "toggle" label or icon + tooltip, plus hover styles
(see for example

[https://github.com/django/django/commit/3f6d939c62efd967f548c27a265748cc2cc47ca5
how GitHub does it]).
--
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/0107018d4182de8f-3c11f22a-b3e9-467c-849d-8a5a308aae31-00%40eu-central-1.amazonses.com.

Re: [Django] #8307: ImageFile use of width_field and height_field is slow with remote storage backends

2024-01-25 Thread Django

#8307: ImageFile use of width_field and height_field is slow with remote storage
backends
-+-
 Reporter:  sebastian.serrano@…  |Owner:  Jacob
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  File |  Version:  dev
  uploads/storage|
 Severity:  Normal   |   Resolution:
 Keywords:  imagefile height | Triage Stage:  Accepted
  width  |
Has patch:  1|  Needs documentation:  1
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Alan Justino da Silva):

 Replying to [comment:17 john-parton]:
 > I've got a fix that I think should pretty much always work.
 > ...
 > Basically, the FileField.save() method will call the descriptors __set__
 method with the value being a string.

 First, thanks for refreshing this 15yo issue, [comment:17 john-parton].

 That said, I do not see how this solution fixes a template page rendering
 ~10 images from a remote storage as there is no `.save()` involved for
 ''using existing images'':

 When I reopened the issue, my application needed only the URL of the
 files, already stored in the database, thus a O(1) call to DB. That is
 because I needed not to put height and width in the `` HTML tag, as
 the browser deals with whatever it fetches from the URL. If grabbing the
 URL keeps forcing to `.get_image_dimentions()`, then this call becomes
 O(10) calls to the storage, meaning O(10) HTTP HEAD calls to S3. That is
 why I proposed ''the storage'' to decide if this should be done, or
 cached, or faked.

 Do you think that letting the storage proxy the image dimensions would be
 another way to fix your issues as well?
-- 
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/0107018d4178da4d-70033122-4297-42c4-bb8c-314876b77bbf-00%40eu-central-1.amazonses.com.

Re: [Django] #35140: Increase font size in Django debug views (404, 500, etc)

2024-01-25 Thread Django

#35140: Increase font size in Django debug views (404, 500, etc)
-+-
 Reporter:  Eliana Rosselli  |Owner:  Eliana
 |  Rosselli
 Type:  Bug  |   Status:  assigned
Component:  Uncategorized|  Version:  5.0
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility font   | Triage Stage:  Accepted
  size   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  1
-+-
Comment (by Thibaud Colas):

 hi Natalia, sure! We reviewed the error pages and noticed the font size
 used there was smaller than recommended minimums on the web. There isn’t a
 hard and fast rule with what’s considered the bare minimum font size or
 how to set a type scale, but general best practice is that the main "body"
 copy of a page should be 16px. As you’ve noted some organizations are also
 using 14px, which I think would make for a good minimum for Django – but
 if we used that for the main copy, then it wouldn’t leave much room for
 any other text to be smaller. So this is possible but would somewhat limit
 design options.

 I don’t know which debug page you’re referring to, the 404 page shared by
 Eli uses 13px for the main text in my browser. For the [https://static-
 django-demo.netlify.app/django_admin_tests/v5.1/english/defaults/500/ 500
 page], my browser’s CSS overview says:

 - 368 occurrences of 13px
 - 14 occurrences of 15.21px
 - 8 occurrences of 11px
 - 7 occurrences of 19.5px
 - 3 occurrences of 13.65px
 - 2 occurrences of 26px

 I don’t see any use of a 14px font size but it could be our browsers are
 configured differently.

 > I wouldn't want the 404 (or 500) pages to have bigger size because then
 users will have to scroll more, and also increasing the font size is a
 shortcut away (ctrl +) or a setting away ("minimum font size" in Firefox
 for example).

 Generally with web accessibility the idea is that the default experience
 should be accessible to the widest audience. So it’d be better to provide
 a legible font size by default, and as you mention if some people find it
 too big or on the contrary not big enough they can still adjust.

 Scrolling is certainly a consideration but it doesn’t seem like font size
 would change things much on those pages?

 - On the 404 and CSRF failure pages, the content has a small height as-is
 and I don’t see how an increase in font size would cause scrolling
 - On the 500 and 400 pages, making the Settings or Request information
 "META" sections would help a lot more than keeping font size small
-- 
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/0107018d4175f49a-e8cdeac5-ab68-4cb1-99bc-3253f4b8d9a2-00%40eu-central-1.amazonses.com.

Re: [Django] #35141: CACHE_MIDDLEWARE_SECONDS can be set to a float but has to be an int

2024-01-25 Thread Django

#35141: CACHE_MIDDLEWARE_SECONDS can be set to a float but has to be an int
-+-
 Reporter:  Alexander Lazarević  |Owner:  Alexander
 Type:   |  Lazarević
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Cache system)  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Tim Graham):

 Certainly, but I wonder if it's Django's responsibility (and any third-
 party code that uses the setting) to silently correct such a mistake. I
 see some precedent in #31982 although there isn't much elaboration on the
 rationale.

 If we are going down this route, should reopen #35041 and do the same (as
 well as do a more extensive audit throughout Django and handle this
 pattern proactively)?
-- 
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/0107018d413f930b-901e09b6-165a-4a2c-b603-da6c8575162f-00%40eu-central-1.amazonses.com.

Re: [Django] #35143: Improve accessibility of error page(s) with semantic HTML

2024-01-25 Thread Django

#35143: Improve accessibility of error page(s) with semantic HTML
-+-
 Reporter:  Marijke Luttekes |Owner:  Marijke
 Type:   |  Luttekes
  Cleanup/optimization   |   Status:  assigned
Component:  Error reporting  |  Version:  5.0
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility, HTML  | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Marijke Luttekes):

 * owner:  nobody => Marijke Luttekes
 * status:  new => assigned

Comment:

 I will pick this up, as discussed with Thibaud earlier!
-- 
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/0107018d41153891-874ed4e9-e09a-4b61-b2ad-f167703237ae-00%40eu-central-1.amazonses.com.

Re: [Django] #35141: CACHE_MIDDLEWARE_SECONDS can be set to a float but has to be an int

2024-01-25 Thread Django

#35141: CACHE_MIDDLEWARE_SECONDS can be set to a float but has to be an int
-+-
 Reporter:  Alexander Lazarević  |Owner:  Alexander
 Type:   |  Lazarević
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Cache system)  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Alexander Lazarević):

 But a float for `max-age` is definitely wrong.

 {{{
 'Cache-Control': 'max-age=3.1415927'
 }}}
-- 
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/0107018d40f11400-bde52635-0f31-42d8-9eea-c2f1f0747408-00%40eu-central-1.amazonses.com.

Re: [Django] #28296: Add support for aggregation through subqueries

2024-01-25 Thread Django

#28296: Add support for aggregation through subqueries
-+-
 Reporter:  László Károlyi   |Owner:  B
 |  Martsberger
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Ionel Cristian Mărieș):

 * cc: Ionel Cristian Mărieș (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/0107018d40d66c6d-caf6067c-61a8-410a-a115-e22303975db6-00%40eu-central-1.amazonses.com.

Re: [Django] #35141: CACHE_MIDDLEWARE_SECONDS can be set to a float but has to be an int

2024-01-25 Thread Django

#35141: CACHE_MIDDLEWARE_SECONDS can be set to a float but has to be an int
-+-
 Reporter:  Alexander Lazarević  |Owner:  Alexander
 Type:   |  Lazarević
  Cleanup/optimization   |   Status:  assigned
Component:  Core (Cache system)  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  1
  Needs tests:  1|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Tim Graham):

 I'm not sure we want to go down the path of casting every integer setting?
 (e.g. #35041 for `DATA_UPLOAD_MAX_MEMORY_SIZE` was recently a wontfix.)
-- 
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/0107018d40ba3c67-e13bc674-20d9-40c5-b05d-fa1af5875377-00%40eu-central-1.amazonses.com.

Re: [Django] #35144: Inconsistency in apostrophe symbols of translatable strings. And broken translations

2024-01-25 Thread Django

#35144: Inconsistency in apostrophe symbols of translatable strings. And broken
translations
-+-
 Reporter:  Mārtiņš Šulcs|Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:   |  Version:  5.0
  Internationalization   |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Mariusz Felisiak):

 Source messages are updated on Transifex for each version (so you will
 find `’` there), however, we don't fetch translations for languages
 without any new translated strings. That's why there is `'` in the source
 code for many-years untouched translations.
-- 
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/0107018d40b7a88c-a35c9591-7da2-464b-a28e-3e9ad958612d-00%40eu-central-1.amazonses.com.

Re: [Django] #35144: Inconsistency in apostrophe symbols of translatable strings. And broken translations

2024-01-25 Thread Django

#35144: Inconsistency in apostrophe symbols of translatable strings. And broken
translations
-+-
 Reporter:  Mārtiņš Šulcs|Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:   |  Version:  5.0
  Internationalization   |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Mārtiņš Šulcs):

 Thanks. So it's supposed to be `’` everywhere. I will see how to report
 this in Transifex.

 Just to understand how this works and what happened. Source messages get
 changed without updating the keys and that invalidates all the
 translations in Transifex so they need to be resubmitted?
-- 
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/0107018d40b285bb-d01732b2-ecce-4f51-8e77-1786fd4c1633-00%40eu-central-1.amazonses.com.

Re: [Django] #34977: Turn link to change password form in admin user change form into a button

2024-01-25 Thread Django

#34977: Turn link to change password form in admin user change form into a 
button
-+-
 Reporter:  Fabian Braun |Owner:  Fabian
 Type:   |  Braun
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.auth |  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-
Comment (by Natalia Bidart):

 Replying to [comment:9 Abhii67534]:
  I would like to work on this issue :)

 Thank you for your interest in helping, but there is already a submitted
 PR solving this issue, we are just waiting on some specific feedback.
-- 
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/0107018d40ac650e-73543024-5774-4424-a670-8a416529e72f-00%40eu-central-1.amazonses.com.

Re: [Django] #34977: Turn link to change password form in admin user change form into a button

2024-01-25 Thread Django

#34977: Turn link to change password form in admin user change form into a 
button
-+-
 Reporter:  Fabian Braun |Owner:  Fabian
 Type:   |  Braun
  Cleanup/optimization   |   Status:  assigned
Component:  contrib.auth |  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:  accessibility| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  1|UI/UX:  1
-+-
Comment (by Abhii67534):

 I would like to work on this issue :)
-- 
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/0107018d40a65a66-7c87f25a-d8a5-4c8d-8a8b-161a29cb678f-00%40eu-central-1.amazonses.com.

Re: [Django] #35144: Inconsistency in apostrophe symbols of translatable strings. And broken translations

2024-01-25 Thread Django

#35144: Inconsistency in apostrophe symbols of translatable strings. And broken
translations
-+-
 Reporter:  Mārtiņš Šulcs|Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:   |  Version:  5.0
  Internationalization   |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Mariusz Felisiak):

 `lt` contains old strings with `'` because no one has translated any new
 strings in it since 2017.
-- 
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/0107018d40a54249-f1aa0992-2e50-4b6f-8cf8-b4f4c1570c78-00%40eu-central-1.amazonses.com.

Re: [Django] #35142: DATE and DATETIME settings have no effect since USE_L10N was deprecated

2024-01-25 Thread Django

#35142: DATE and DATETIME settings have no effect since USE_L10N was deprecated
-+-
 Reporter:  Paul |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:   |  Version:  5.0
  Internationalization   |
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  USE_L10N,| Triage Stage:
  localization   |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Description changed by Paul:

Old description:

> Since 5.0 **USE_L10N** settings was DEPRECATED and is always True.
>
> Now settings like **DATE_FORMAT**, **DATETIME_FORMAT**,
> **DATE_FORMAT_INPUTS** etc.. don't work because as per documentation:
> "Note that the locale-dictated format has higher precedence and will be
> applied instead. But now locale-dictated formats are always enabled."
> Now locale-dictated formats will always have higher precedence.
>
> It alse breaks editing on all ModelForms which have date and datetime
> fields because the input is expecting ISO format, but Django forcefully
> localizes the value attribute to another format.
>
> I've found a solution but overriding the formats.py file using the
> **FORMAT_MODULE_PATH** setting. I think at least the documents should
> make it clear you can do that.

New description:

 Since 5.0 **USE_L10N** settings was DEPRECATED and is always True.

 Now settings like **DATE_FORMAT**, **DATETIME_FORMAT**,
 **DATE_FORMAT_INPUTS** etc.. don't work because as per documentation:
 "Note that the locale-dictated format has higher precedence and will be
 applied instead. But now locale-dictated formats are always enabled."
 Now locale-dictated formats will always have higher precedence.

 It alse breaks editing on all ModelForms which have date and datetime
 fields because the input is expecting ISO format, but Django forcefully
 localizes the value attribute to another format.

 I've found a solution but overriding the formats.py file using the
 **FORMAT_MODULE_PATH** setting. I think at least the documents should make
 it clear you can do that.

 DEMO PROJECT: https://github.com/paulik123/django-demo-l10n

--
-- 
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/0107018d40a40d01-576d567e-bead-478a-9703-cd77fc03bbfc-00%40eu-central-1.amazonses.com.

Re: [Django] #35142: DATE and DATETIME settings have no effect since USE_L10N was deprecated

2024-01-25 Thread Django

> I don't think that it's true, can you provide a sample project that
reproduces your issue.
I've created a demo project at https://github.com/paulik123/django-demo-
l10n
Just create a demo object then click edit.

> True, if you don't like formats provided for a language you're working
with, you can use FORMAT_MODULE_PATH to specify your own format
definitions. This setting is documented, I'm not sure what else are you
trying to propose.

Yes, but not specifying that all format settings (DATE_FORMAT,
DATETIME_FORMAT etc) won't work if you just paste them settings.py seems
confusing to me. I think at least a note should be added saying that to
modify these settings you need to override formats.py

Replying to [comment:1 Mariusz Felisiak]:
--
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/0107018d40a2ef16-502c7b68-508a-4523-a024-068971ffe40a-00%40eu-central-1.amazonses.com.

Re: [Django] #35144: Inconsistency in apostrophe symbols of translatable strings. And broken translations

2024-01-25 Thread Django

#35144: Inconsistency in apostrophe symbols of translatable strings. And broken
translations
-+-
 Reporter:  Mārtiņš Šulcs|Owner:  nobody
 Type:  Uncategorized|   Status:  closed
Component:   |  Version:  5.0
  Internationalization   |
 Severity:  Normal   |   Resolution:  invalid
 Keywords:   | Triage Stage:
 |  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

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

Comment:

 > I'm not familiar with how Transifex operates and whether this should be
 fixed in the translation.

 Yes, this should be fixed in Transifex by translators.

 > However, the inconsistency in the source doesn't seem ideal.

 What kind of inconsistency are you talking about? We put efforts to
 improve typography of user facing strings everywhere in the source code
 (check out #30400).
-- 
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/0107018d40a20208-a911726b-c314-48a6-88f1-0b555e964bba-00%40eu-central-1.amazonses.com.

[Django] #35144: Inconsistency in apostrophe symbols of translatable strings. And broken translations

2024-01-25 Thread Django

#35144: Inconsistency in apostrophe symbols of translatable strings. And broken
translations
+
Reporter: Mārtiņš Šulcs | Owner: nobody
Type: Uncategorized | Status: new
Component: Internationalization |Version: 5.0
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 |
+
The usage of apostrophe symbols in source code is inconsistent, sometimes
it's `’`(0x2019), and other times it's `'`(0x27). From what I understand,
gettext does not normalize this.
Looking at the translations of contrib.auth, there are several broken
keys. For instance:

Message source -

[Link](https://github.com/django/django/blob/main/django/contrib/auth/password_validation.py#L266)
Correct id -

[Link](https://github.com/django/django/blob/main/django/contrib/auth/locale/lv/LC_MESSAGES/django.po#L270)
Wrong id -

[Link](https://github.com/django/django/blob/main/django/contrib/auth/locale/lt/LC_MESSAGES/django.po#L277)

Grepping shows there are other places where `’` is used in translatable
strings but this is the place we encountered broken translation.

I'm not familiar with how Transifex operates and whether this should be
fixed in the translation. However, the inconsistency in the source doesn't
seem ideal.
--
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/0107018d4089ccd5-e41e303e-f676-4769-beb5-0d30d1e846b1-00%40eu-central-1.amazonses.com.

Re: [Django] #35136: Interoperability with intarray PostgreSQL extension

2024-01-25 Thread Django

Thank you for a timely reply.

> I don't think that Django can commit to producing SQL that is compatible
with all the combination of usage of Postgres extensions out there.

I feel this is somewhat unfair. I am not asking for perfect support of
every possible extension out there. Django already supports multiple
PostgreSQL extensions. The `intarray` is another one of the handful of
extensions bundled with PostgreSQL and available out of the box on
mainstream Linux distributions. It doesn't feel like a stretch to expect
Django won't break if I enable it, but I won't press you.

Thanks for a cleaner workaround.
--
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/0107018d408581d1-89486233-f59a-47bf-b025-b8090232211a-00%40eu-central-1.amazonses.com.

Re: [Django] #35140: Increase font size in Django debug views (404, 500, etc)

2024-01-25 Thread Django

Hello Eliana, Thibaud!

I'm on the fence with this ticket, could you please explain a bit more the
issue with the font size? I see the debug page with font 14px but I also
see Google and other web sites to be 14px. I wouldn't want the 404 (or
500) pages to have bigger size because then users will have to scroll
more, and also increasing the font size is a shortcut away (ctrl +) or a
setting away ("minimum font size" in Firefox for example).

I'm not opposed but I'm not a fan either, so I'd like to know more before
proceeding. Thank you!
--
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/0107018d407ab080-d1188f2f-9e01-415e-af9e-dc0e0e6c26aa-00%40eu-central-1.amazonses.com.

Re: [Django] #35142: DATE and DATETIME settings have no effect since USE_L10N was deprecated

2024-01-25 Thread Django

* status: new => closed
* resolution: => needsinfo
* component: Uncategorized => Internationalization
* type: Bug => Cleanup/optimization

Comment:

> It alse breaks editing on all ModelForms which have date and datetime
fields because the input is expecting ISO format, but Django forcefully
localizes the value attribute to another format.

I don't think that it's true, can you provide a sample project that
reproduces your issue.

> I've found a solution but overriding the formats.py file using the
FORMAT_MODULE_PATH setting. I think at least the documents should make it
clear you can do that.

True, if you don't like formats provided for a language you're working
with, you can use `FORMAT_MODULE_PATH` to specify your own format
definitions. This setting is documented, I'm not sure what else are you
trying to propose.
--
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/0107018d40270d90-b253e462-33f9-427c-bb06-6a9f5c604fbf-00%40eu-central-1.amazonses.com.

Re: [Django] #29280: Add a database OPTIONS to specify the transaction mode one SQLite.

2024-01-25 Thread Django

#29280: Add a database OPTIONS to specify the transaction mode one SQLite.
-+-
 Reporter:  Ove Kåven|Owner:  Anže
 |  Pečar
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite, databases| Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * has_patch:  0 => 1
 * stage:  Ready for checkin => Accepted

Comment:

 [https://github.com/django/django/pull/17760 PR]. Please don't mark your
 own PRs as "Ready for checkin".
-- 
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/0107018d4020148b-b0c780cf-3a42-48e1-b0b8-c959921d50b0-00%40eu-central-1.amazonses.com.

Re: [Django] #35143: Improve accessibility of error page(s) with semantic HTML

2024-01-25 Thread Django

#35143: Improve accessibility of error page(s) with semantic HTML
--+
 Reporter:  Marijke Luttekes  |Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Error reporting   |  Version:  5.0
 Severity:  Normal|   Resolution:
 Keywords:  accessibility, HTML   | Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+
Changes (by Mariusz Felisiak):

 * component:  contrib.admin => Error reporting
 * stage:  Unreviewed => Accepted

Comment:

 Agreed. Accessibility improvements are always welcome.
-- 
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/0107018d401e4a09-acde2460-3b9b-4e83-86d9-322b9c6d3592-00%40eu-central-1.amazonses.com.

[Django] #35143: Improve accessibility of error page(s) with semantic HTML

2024-01-25 Thread Django

The following changes should be simple, without altering the look and feel
of the page:

1. The page should have a header, main, and footer.
2. Each table should have scope attributes on th elements.
3. Monospaced text in the patterns list should use a code element.
4. The small text within the h1 should use a small element instead of a
span.

Discussed with accessibility team member Thibaud Colas, who made this
example page for the HTTP 404 error:
https://static-django-
demo.netlify.app/django_admin_tests/v5.1/english/defaults/404/
--
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/0107018d401172dd-0940ce6d-c80b-4235-acc7-b6f590a08e58-00%40eu-central-1.amazonses.com.

[Django] #35142: DATE and DATETIME settings have no effect since USE_L10N was deprecated

2024-01-25 Thread Django

Now settings like **DATE_FORMAT**, **DATETIME_FORMAT**,
**DATE_FORMAT_INPUTS** etc.. don't work because as per documentation:
"Note that the locale-dictated format has higher precedence and will be
applied instead. But now locale-dictated formats are always enabled."
Now locale-dictated formats will always have higher precedence.

It alse breaks editing on all ModelForms which have date and datetime
fields because the input is expecting ISO format, but Django forcefully
localizes the value attribute to another format.

I've found a solution but overriding the formats.py file using the
**FORMAT_MODULE_PATH** setting. I think at least the documents should make
it clear you can do that.
--
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/0107018d3ff4c548-ba7ea3bd-d2c5-4961-b7e8-c01b387060fd-00%40eu-central-1.amazonses.com.

Re: [Django] #29280: Add a database OPTIONS to specify the transaction mode one SQLite.

2024-01-25 Thread Django

#29280: Add a database OPTIONS to specify the transaction mode one SQLite.
-+-
 Reporter:  Ove Kåven|Owner:  Anže
 |  Pečar
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  2.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  sqlite, databases| Triage Stage:  Ready for
 |  checkin
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Anže Pečar):

 * stage:  Accepted => Ready for checkin

-- 
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/0107018d3fd62ddf-0386bb69-5ace-48d0-8e19-b3c478b0f0e4-00%40eu-central-1.amazonses.com.

Re: [Django] #35058: Update GDAL integration

2024-01-25 Thread Django

#35058: Update GDAL integration
-+-
 Reporter:  David Smith  |Owner:  David
 Type:   |  Smith
  Cleanup/optimization   |   Status:  closed
Component:  GIS  |  Version:  4.2
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * status:  assigned => closed
 * needs_better_patch:  1 => 0
 * resolution:   => fixed

-- 
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/0107018d3fcdffe4-83242d1a-e1c8-4f3f-bbd2-b10b5439280d-00%40eu-central-1.amazonses.com.

Re: [Django] #35058: Update GDAL integration

2024-01-25 Thread Django

#35058: Update GDAL integration
-+-
 Reporter:  David Smith  |Owner:  David
 Type:   |  Smith
  Cleanup/optimization   |   Status:  assigned
Component:  GIS  |  Version:  4.2
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Comment (by Mariusz Felisiak ):

 In [changeset:"3f6d939c62efd967f548c27a265748cc2cc47ca5" 3f6d939c]:
 {{{#!CommitTicketReference repository=""
 revision="3f6d939c62efd967f548c27a265748cc2cc47ca5"
 Refs #35058 -- Added support for measured geometries to GDAL Point.

 Co-authored-by: Nick Pope 
 }}}
-- 
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/0107018d3fcb82cf-ad4186ea-0cdd-451f-85c3-2588fce0ed3c-00%40eu-central-1.amazonses.com.

41 matches

Mail list logo