Re: Drop CSRF middleware from the settings template

[Deepak Sain]

hello everyone i am deepak kumar sain new to tensorflow also new to 
opensource contributiuons , i am an student , i want to start my open 
source contribution journey can anyone helpme how can i contribute and what 
can i contribute am learning DSA in c++ and Flutter currently . thank you


On Friday, 5 May 2023 at 18:55:38 UTC+5:30 Ryan Hiebert wrote:

> I've been working on setting up a new project that's never going to see 
> the light of production, so I went down the road of just disabling CSRF for 
> that purpose. I notably found that the Django admin still requires CSRF, 
> even when the middleware has been removed from the MIDDLEWARE setting. I 
> found this because the development environment I was working in, 
> Codespaces, forwards and redirects to a browser via a public address rather 
> than localhost, and that difference means that CSRF checks were enforced in 
> that environment, though I had no trouble with localhost. There's likely 
> some details I'm missing in laying out this scenario, but it felt 
> interesting enough to mention in the context of this conversation.

-- 
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/30877bdf-e468-4f28-ae4f-7324521a9c79n%40googlegroups.com.

Re: Permissions don't get translated in admin interface

[Thibaud Colas]

👋 without further input, I’m not quite sure what to do with this. We need 
this ticket re-opened so anyone actually considers working on a fix for 
this. For reference, the initial reason for closing this bug report was:

> The permissions are stored in the database and don't get translated.

To me at least this is a poor reason. First off this is still a clear bug 
from the perspective of people who expect the admin to be in the language 
of their choosing. Second, there are clear ways to improve upon this even 
without significantly re-engineering how permission names are generated 
(see message above – and my proof of concept 
).

Any takers? Should I post this elsewhere?
On Friday, 14 October 2022 at 05:45:34 UTC+1 Thibaud Colas wrote:

> I worked on a potential fix for this yesterday at the Django London’s hack 
> day with Nick (hi Nick if you’re reading this!). 
>
>- Here is where translation names get created: 
>
> https://github.com/django/django/blob/main/django/contrib/auth/management/__init__.py#L31
>- And where the strings are generated for display: 
>
> https://github.com/django/django/blob/main/django/contrib/auth/models.py#L78
>- As well as: 
>
> https://github.com/django/django/blob/main/django/contrib/contenttypes/models.py#L150
>
> And here is a draft PR that makes those labels fully translate-able at 
> least for the default permissions: 
> https://github.com/thibaudcolas/django/pull/1
>
> It seems to work well. As far as I could see, there’s no reason for at 
> least the app name to be displayed in english (just need to switch from 
> app_label to verbose_name).
> On Sunday, 25 September 2022 at 14:02:33 UTC+1 Thibaud Colas wrote:
>
>> Thank you all for your suggestions so far :) Just to give a little bit 
>> more background – aside from ticket #1688 Permissions don't get 
>> translated in admin interface 
>> , this had also been 
>> discussed in Translation of group permissions 
>>  
>> on 
>> the mailing list (though it’s not just for groups).
>>
>> To clarify what I’m after – in my opinion this needs to be treated as a 
>> bug to fix in Django itself – at least for translations of built-in 
>> permissions. Having a way to do this for custom ones would be nice too (see 
>> for example Wagtail issue #5341 
>> ). So devising how to 
>> fix this would be nice, but right now this is officially a "wontfix" so 
>> this would need to be addressed first.
>>
>> For reference, here is a screenshot of the current state, in Arabic 
>> (right-to-left language so the UI is partly mirrored):
>>
>> [image: translations-current-state.png]
>>
>> Translation names aren’t translated, while their model names are 
>> translated, and the app name isn’t translated ("auth" vs. app label 
>> "المصادقة والتفويض" in the sidebar).
>> On Sunday, 25 September 2022 at 12:12:21 UTC+1 ramez...@gmail.com wrote:
>>
>>> Hello 
>>>
>>> it's for this reason, i created this package 
>>> https://github.com/RamezIssac/django-tabular-permissions
>>> It displays the permissions in a table that is easily translated , and 
>>> easier to work with
>>>
>>> Aside from a 3rd party app, a workaround (like the one suggested above) 
>>> will be the way to go.
>>> For Django core, it think its very hard to do it as one can also have 
>>> more than one non English of languages supported .. which permission 
>>> language will be recorded in the database then ?
>>>
>>> Screen shot for tabular permissions
>>> [image: tabular_permisions.png]
>>>
>>> On Sunday, September 25, 2022 at 3:07:27 AM UTC+2 baido...@gmail.com 
>>> wrote:
>>>
 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-d...@googlegroups.com [mailto:
> djan

Re: Permissions don't get translated in admin interface

[Mariusz Felisiak]

Is it not partly fixed by a52bdea5a27ba44b13eda93642231c65c581e083 

?

-- 
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/999dfe6a-230e-4bd7-b3f4-455142d24c6en%40googlegroups.com.

Re: Permissions don't get translated in admin interface

[Thibaud Colas]

Ah-ha! Correct :) That’s great. So as of that commit, it’s just the 
permission names that aren’t translated. Here’s a screenshot of the current 
state:

[image: permission-names-django-Django-5.0.dev20230602105440.png]

I’ve updated my POC accordingly 
(https://github.com/thibaudcolas/django/pull/1), the implementation is 
still hacky but now only requires changes in the Permission model.

On Friday, 2 June 2023 at 19:40:04 UTC+1 Mariusz Felisiak wrote:

> Is it not partly fixed by a52bdea5a27ba44b13eda93642231c65c581e083 
> 
> ?
>
>

-- 
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/de16efdf-f825-41cc-bf6a-9a820f9db2efn%40googlegroups.com.

Re: Permissions don't get translated in admin interface

[Thibaud Colas]

As suggested by @nessita on Discord, I’ve taken this to the Django Forum in 
Django 
Internals: 
https://forum.djangoproject.com/t/permissions-dont-get-translated-in-admin-interface/21324.

Let’s try to keep the discussion going over there!

On Friday, 2 June 2023 at 20:58:50 UTC+1 Thibaud Colas wrote:

> Ah-ha! Correct :) That’s great. So as of that commit, it’s just the 
> permission names that aren’t translated. Here’s a screenshot of the current 
> state:
>
> [image: permission-names-django-Django-5.0.dev20230602105440.png]
>
> I’ve updated my POC accordingly (
> https://github.com/thibaudcolas/django/pull/1), the implementation is 
> still hacky but now only requires changes in the Permission model.
>
> On Friday, 2 June 2023 at 19:40:04 UTC+1 Mariusz Felisiak wrote:
>
>> Is it not partly fixed by a52bdea5a27ba44b13eda93642231c65c581e083 
>> 
>> ?
>>
>>

-- 
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/4d06cb27-ef19-4cd6-98be-6cf1d68d20ffn%40googlegroups.com.

Re: Django t-shirt

[Thibaud Colas]

Hi Fabien, for what it’s worth Django also has merch with FreeWear, who are 
based in Spain: https://www.freewear.org/Django

Cheers,

Thibaud

On Monday, 16 January 2023 at 13:26:25 UTC Fabien Schwob wrote:

> Hello,
>
> It would be awesome to also have a Threadless alternative for Europe, to 
> avoid huge delivery costs and customs fees.
>
> Best regards,
>
> Dim 15 janv 2023, à 09:03, 'Adam Johnson' via Django developers  
> (Contributions to Django itself) a écrit :
>
> There is a Django Threadless store where you can buy T-Shirts and other 
> merchandise, which all supports the DSF: https://django.threadless.com/
>
> It’s linked from the fundraising page: 
> https://www.djangoproject.com/fundraising/
>
> I have a Django phone case from there!
>
> On Fri, Jan 13, 2023 at 11:44 AM Stephen Wolff  
> wrote:
>
> Hi there,
>
> A few Django versions ago (1.7 and maybe 1.8?!), t-shirts were produced 
> and sold (i guess for fundraising purposes?).
>
> Just wondering given the forthcoming LTS is 4.2, which has similarities to 
> Douglas Adams's answer to the life, universe and everything, whether a new 
> t-shirt could be produced?
>
> Yours hopefully,
>
> Stephen
>
>
> -- 
> 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-develop...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/7570a944-3822-4493-acf0-4510c24e7b8bn%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-develop...@googlegroups.com.
>
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAMyDDM2jQx2RTyDktvi%2BTCMa%3D4PR43SXPpwxv7V9A8bL-z-hEA%40mail.gmail.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/a75c0e16-1670-464d-9d6e-20835ba22df8n%40googlegroups.com.

Re: Model icons

[Thibaud Colas]

Hi all, I see Wagtail has been mentioned, we actually shipped a lot of 
improvements to our icons support in our last release, thought I’d share a 
few details in case it helps in considering this for Django.

Here is Wagtail’s documentation for custom 
icons: https://docs.wagtail.org/en/stable/advanced_topics/icons.html. The 
TL;DR; is:

   - Icons are SVG files, registered in the CMS with a unique identifier 
   (for example "fa-user-solid")
   - This makes it possible to create "icon pack" packages 
   ("django-fontawesome", "django-myiconset"), which register large amounts of 
   icons. And also allows for specific projects to register their own custom 
   icon(s).
   - In different parts of the code (Wagtail’s ModelAdmin equivalents), we 
   allow providing an icon identifier.
   - We have a set of built-in icons, most from FontAwesome, some custom.
   - icons are then loaded as an inline SVG "sprite" (SVG symbol elements).


As an aside, the Django admin’s current iconography is in a dire need of 
being rebuilt. Its implementation with `img` elements and background images 
is really less than ideal for accessibility, because it makes it really 
hard to style icons according to different needs (light theme, dark theme, 
high contrast mode) and UI states (error, focus, etc).

Cheers,

Thibaud

On Friday, 3 March 2023 at 15:08:24 UTC Bogdan Barna wrote:

>
> Hello all,
>
> I've joined this emailing list just to support the fellow users, of not 
> adding this (especially on models.Model) as per their points made.
>
> Thanks,
> Bogdan
>
> On Thursday, February 23, 2023 at 5:54:44 PM UTC+2 Jacob Rief wrote:
>
>> On Thu, Feb 23, 2023 at 7:38 AM Brice Parent  wrote:
>>
>>> Hello!
>>>
>>> Really useful idea, I think! 2 points about it: 
>>>
>>> 1. Syntax
>>>
>>> I would also remove the html from the models, but probably in this way:
>>> class Hammer(models.Model):
>>> ...
>>>
>>> Meta:
>>> icon = ModelIcon("🔨")
>>>
>>>
>>> There would be something like 
>>>
>>> ModelIcon.as_html(self, model_name:str) -> str:
>>> """returns whatever html should be used in the admin"""
>>>
>>>
>>> or a ModelIcon.set_text(self, text: str) and we'd use a simple 
>>> str(model_icon) in the templates.
>>>
>>> In my opinion, Django models shall not have to specify parts of their 
>> representation layer, such as icons.
>> This shall be left exclusively to the view layer: The ModelAdmin is such 
>> a candidate.
>>
>> That way, it could be extended easily in a 
>>> FontAwesomeModelIcon("fa-hammer") and a BootstrapModelIcon("bi-hammer") for 
>>> example, and maybe get whatever extra arguments they may need, like 
>>> FontAwesomeModelIcon("fa-hammer", thickness="solid").
>>>
>>> I don't like the idea that Django becomes dependent on any 
>> UTF-8-Symbol/Dingbats/Emojis/Glyphicon/Font-Awesome/Bootstrap/Remix/etc-Iconset.
>> Some Models might have a purpose which can not be mapped to any of those 
>> icons and need to be custom designed.
>>  
>>
>>> 2. Make it more widely useful
>>> I like the fact that it's in the model itself and not in the modeladmin, 
>>> as it allows to use it elsewhere, like in the __str__ to quickly add this 
>>> visual indication of the class. Boostrap and co would have to provide a 
>>> non-html version of the icon or return an empty string though.
>>>
>>> That's a violation of the well established MVC pattern of keeping the 
>> visual part in the view, and the "business model" within the model.
>>
>> Just my 2 cents
>> – Jacob
>>
>

-- 
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/7d9fa096-8105-47ab-a778-537294ddccf9n%40googlegroups.com.