Permissions don't get translated in admin interface

[Thibaud Colas]

👋 there have been a lot of discussions and tickets opened on permissions 
translations in the past. I’m not sure what the etiquette here is, hence 
why I’m starting a new conversation.

I would like to see #1688 Permissions don't get translated in admin 
interface  reconsidered, as to 
me it seems like a clear bug, which affects a lot of users. Though not many 
people might be managing permissions regularly, when you do, it’s very 
jarring that the text is in the wrong language.

I’m not sure what Django’s stance is on supporting non-english users 
generally, but based on our diversity statement I feel like "100% of the 
admin UI translated" is an important goal – and looking at Transifex 
, there are a lot of people 
putting in a lot of effort to get it there. If this is a wontfix because 
the store-label-in-DB approach is effectively impossible to make work, then 
I think this would be worth clearing documenting on the Localizing Django 
 
page so translators know what to expect. Ideally also mention elsewhere in 
a place visible to end users.

---

>From a technical perspective, this is far from my area of expertise but as 
I understand there are clear solutions – one that’s "quick and dirty" would 
be to hard-code a list of gettext_lazy calls with the same labels as stored 
in the DB for the purpose of collecting the labels for PO files, and then 
we could use {% translate %} over the DB-provided values anyway. No change 
to the DB needed. I count 8 Django-provided models in my demo site (might 
be missing others), each has 4 Django-provided permissions, so that’s 32 
strings to hard-code. Feels doable!


-- 
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/8e14c59f-3331-401a-85a1-cbf27d49fe65n%40googlegroups.com.

Solutions for ticket #31506

[David Sanders]

Hi folks,

Ticket 31506  is an older
ticket that I thought I'd look into – there are a couple of points of
discussion I thought I'd run past folks before offering a PR.

To summarise the issue:

On Postgres when you add or subtract an interval with a date the result is
a timestamp
.
The issue reports that if you have a queryset to calculate an interval,
then using ExpressionWrapper to define the output_field essentially ignores
the response type that the db returns.

Eg:

class StartModel(Model):
start = DateField()

StartModel.objects.create(start=date(2022, 1, 1))
qs = StartModel.objects.annotate(
end=ExpressionWrapper(F("start") + timedelta(days=1),
output_field=DateField())
)
print(type(qs.first().end))


This raises a couple of questions:

*1.* Is this the responsibility of ExpressionWrapper (or the relevant db
backend) to ensure the correct types are returned or is it the
responsibility of the developer to use Cast() ?

The equivalent with Cast() returns the correct type:
qs = StartModel.objects.annotate(end=Cast(F("start") + timedelta(days=1),
output_field=DateField()))
print(type(qs.first().end))


If so, should the ticket be marked as *wontfix*?

*2.* If it is Django's responsibility there are a couple of solutions that
work (fixes failing test attached to the ticket):

*a. Add a db converter:*
diff --git a/django/db/backends/postgresql/operations.py
b/django/db/backends/postgresql/operations.py
index 2303703ebc..e4158b8130 100644
--- a/django/db/backends/postgresql/operations.py
+++ b/django/db/backends/postgresql/operations.py
@@ -1,3 +1,4 @@
+from datetime import datetime
 from psycopg2.extras import Inet

 from django.conf import settings
@@ -354,3 +355,15 @@ class DatabaseOperations(BaseDatabaseOperations):
 update_fields,
 unique_fields,
 )
+
+def get_db_converters(self, expression):
+converters = super().get_db_converters(expression)
+internal_type = expression.output_field.get_internal_type()
+if internal_type == "DateField":
+converters.append(self.convert_datefield_value)
+return converters
+
+def convert_datefield_value(self, value, expression, connection):
+if type(value) == datetime:
+value = value.date()
+return value


*b. Manually cast the expression in ExpressionWrapper*diff --git
a/django/db/models/expressions.py b/django/db/models/expressions.py
index 5e3c7cab82..347c107936 100644
--- a/django/db/models/expressions.py
+++ b/django/db/models/expressions.py
@@ -1247,6 +1247,10 @@ class ExpressionWrapper(SQLiteNumericMixin,
Expression):
 def as_sql(self, compiler, connection):
 return compiler.compile(self.expression)

+def as_postgresql(self, compiler, connection):
+sql, params = self.as_sql(compiler, connection)
+return "{}::{}".format(sql,
self.output_field.db_type(connection)), params
+
 def __repr__(self):
 return "{}({})".format(self.__class__.__name__, self.expression)

Any other ideas?

Regards,
David

-- 
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/CADyZw-5UDjiFBKwL94NiF-pHu3AU82nh-A5Y071q%2BhOiMU0Yig%40mail.gmail.com.

Revisiting multiline template tags in Django Templates (again)

[Thibaud Colas]

👋 Hi django-developers, I would like to revisit a very old feature 
request: ticket #8652 Multiline tags and tag escape tags 
, proposed DEP Multiline 
Template Tags , and maling list 
thread Revisiting multiline tags 

.

There have been a lot of cases made against and for multiline template tags 
across many threads. I’m raising this on the mailing list not necessarily 
to revisit those arguments but to ask:

   1. Is a DEP indeed the best way forward for this at this point in time? 
   If so I will volunteer to author it (co-authors welcome!).
   2. The last DEP got blocked due to the lack of an implementation team 
   and shepherd. If we made a new (proposed) DEP – is anyone here interested 
   in helping in either positions?


-- 
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/4f3d0e3b-1fd5-4189-8014-c2aaba157b48n%40googlegroups.com.

Proposal: cacheif template tag

[Igor Margitich]

Hi django-developers,

I would like to propose new template tag `cacheif`. Could be useful when 
you need to cache part of html and it depends on some condition. Template 
tag is similar to built-in `cache` tag but accepts extra boolean parameter. 
See example:

{% cacheif user.is_anonymous 10 homepage %}
  
 .
  
{% endcacheif %}


-- 
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/bcf8ffee-6497-4a55-ba40-913446d15b06n%40googlegroups.com.

Proposal: Make it so when getting an image's dimensions, EXIF orientation is considered

[Adam Taylor]

Following the advice of David Sanders and Mariusz Felisiak, I'm coming here 
with my proposal rather than continuing on with the ticket system (see ticket 
#34035 ).

I understand the reluctance to make this change. However, things change 
with web browsers and I believe web frameworks should make changes to stay 
in line with the web browsers. It used to be less common for web browsers 
to consider EXIF orientation, but now it's the standard. ImageField being 
able to save the image dimensions to another field is very useful but for 
my use case it's broken because it doesn't consider EXIF orientation so 
there are cases where the dimensions are the opposite of what they should 
be. I highly doubt I'm alone in this. Maybe there should be a setting that 
can be passed into ImageField to avoid breaking existing projects. I 
definitely think this should be part of Django rather than having the 
developers need to add this logic to each of their Django projects that 
need it.

Thoughts?

-- 
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/c51cfad1-df74-446a-a341-53a007a9ae9fn%40googlegroups.com.

RE: Permissions don't get translated in admin interface

[Danilov Maxim]

Hi, Tribaud.

 

In your case you can override Permission admin to show translated names of 
permissions and for widgets you can override modelchoiceiterator

The name of permission you can translate like model.verbose_name + gettext( 
‘can’) + gettext(view/change/delete) and it should be translated.

With custom translation is a little bit  more work, but it also works. 

I am not sure, that if override of __str__ helps, but it also possible.

 

 

By the way - My solution DJANGO-TOF 2.version solves you ask without any 
changes in code.

I‘ve presented it on last Django con 2022

We works with permissions and also custom permissions already long time in 
Multilanguage Project and I don’t see any problem with that.

 

 

Mit freundlichen Grüßen,

DI Mag. Maxim Danilov

 

+43(681)207 447 76

  ma...@wpsoft.at

 

From: django-developers@googlegroups.com 
[mailto:django-developers@googlegroups.com] On Behalf Of Thibaud Colas
Sent: Saturday, September 24, 2022 9:25 AM
To: Django developers (Contributions to Django itself) 

Subject: Permissions don't get translated in admin interface

 

👋 there have been a lot of discussions and tickets opened on permissions 
translations in the past. I’m not sure what the etiquette here is, hence why 
I’m starting a new conversation.

 

I would like to see #1688 Permissions don't get translated in admin interface 
  reconsidered, as to me it seems 
like a clear bug, which affects a lot of users. Though not many people might be 
managing permissions regularly, when you do, it’s very jarring that the text is 
in the wrong language.

 

I’m not sure what Django’s stance is on supporting non-english users generally, 
but based on our diversity statement I feel like "100% of the admin UI 
translated" is an important goal – and looking at Transifex 
 , there are a lot of people 
putting in a lot of effort to get it there. If this is a wontfix because the 
store-label-in-DB approach is effectively impossible to make work, then I think 
this would be worth clearing documenting on the Localizing Django 
  
page so translators know what to expect. Ideally also mention elsewhere in a 
place visible to end users.

 

---

 

>From a technical perspective, this is far from my area of expertise but as I 
>understand there are clear solutions – one that’s "quick and dirty" would be 
>to hard-code a list of gettext_lazy calls with the same labels as stored in 
>the DB for the purpose of collecting the labels for PO files, and then we 
>could use {% translate %} over the DB-provided values anyway. No change to the 
>DB needed. I count 8 Django-provided models in my demo site (might be missing 
>others), each has 4 Django-provided permissions, so that’s 32 strings to 
>hard-code. Feels doable!

 

 

-- 
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/8e14c59f-3331-401a-85a1-cbf27d49fe65n%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/01d8d064%24f9d25dd0%24ed771970%24%40wpsoft.at.

Re: Permissions don't get translated in admin interface

[Sarah Baidoo]

Thanks

On Sat, Sep 24, 2022, 22:28 Danilov Maxim  wrote:

> Hi, Tribaud.
>
>
>
> In your case you can override Permission admin to show translated names of
> permissions and for widgets you can override modelchoiceiterator
>
> The name of permission you can translate like model.verbose_name +
> gettext( ‘can’) + gettext(view/change/delete) and it should be translated.
>
> With custom translation is a little bit  more work, but it also works.
>
> I am not sure, that if override of __str__ helps, but it also possible.
>
>
>
>
>
> By the way - My solution DJANGO-TOF 2.version solves you ask without any
> changes in code.
>
> I‘ve presented it on last Django con 2022
>
> We works with permissions and also custom permissions already long time in
> Multilanguage Project and I don’t see any problem with that.
>
>
>
>
>
> Mit freundlichen Grüßen,
>
> DI Mag. Maxim Danilov
>
>
>
> +43(681)207 447 76
>
> ma...@wpsoft.at
>
>
>
> *From:* django-developers@googlegroups.com [mailto:
> django-developers@googlegroups.com] *On Behalf Of *Thibaud Colas
> *Sent:* Saturday, September 24, 2022 9:25 AM
> *To:* Django developers (Contributions to Django itself) <
> django-developers@googlegroups.com>
> *Subject:* Permissions don't get translated in admin interface
>
>
>
> 👋 there have been a lot of discussions and tickets opened on permissions
> translations in the past. I’m not sure what the etiquette here is, hence
> why I’m starting a new conversation.
>
>
>
> I would like to see #1688 Permissions don't get translated in admin
> interface  reconsidered, as
> to me it seems like a clear bug, which affects a lot of users. Though not
> many people might be managing permissions regularly, when you do, it’s very
> jarring that the text is in the wrong language.
>
>
>
> I’m not sure what Django’s stance is on supporting non-english users
> generally, but based on our diversity statement I feel like "100% of the
> admin UI translated" is an important goal – and looking at Transifex
> , there are a lot of people
> putting in a lot of effort to get it there. If this is a wontfix because
> the store-label-in-DB approach is effectively impossible to make work, then
> I think this would be worth clearing documenting on the Localizing Django
> 
> page so translators know what to expect. Ideally also mention elsewhere in
> a place visible to end users.
>
>
>
> ---
>
>
>
> From a technical perspective, this is far from my area of expertise but as
> I understand there are clear solutions – one that’s "quick and dirty" would
> be to hard-code a list of gettext_lazy calls with the same labels as stored
> in the DB for the purpose of collecting the labels for PO files, and then
> we could use {% translate %} over the DB-provided values anyway. No change
> to the DB needed. I count 8 Django-provided models in my demo site (might
> be missing others), each has 4 Django-provided permissions, so that’s 32
> strings to hard-code. Feels doable!
>
>
>
>
>
> --
> 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/8e14c59f-3331-401a-85a1-cbf27d49fe65n%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/01d8d064%24f9d25dd0%24ed771970%24%40wpsoft.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/CAOTfnYZ8cq_VEXNHqz%2BiKvBYOSc8ZrWYQDPFcC50AhghhVmMwg%40mail.gmail.com.