Re: Translation of group permissions

[Ramez Ashraf]

This is an old decision not to store translated strings in the db... and 
it's makes sense what if your site is multi lingual ?
Solution: The widget should be replaced with a another widget that display 
the permissions in a dynamically translated fashion.

There is this app to address that and to address the fact that it's is not 
very user friendly especially when we have an increased number of models 
https://github.com/RamezIssac/django-tabular-permissions
*Disclaimer: i'm the author of this library.*
 

On Saturday, May 22, 2021 at 9:04:17 AM UTC+2 fran.h...@gmail.com wrote:

> I ran into this same issue last week. That ticket raises a valid question 
> IMHO: why even save permission descriptions in the DB? 
>
> Anyone seeing any downsides of the proposed approach to fetch the 
> descriptions from code (and apply translation on the fly)?
>
> Fran
>
> On 22.05.2021., at 02:08, macie...@gmail.com  wrote:
>
> Hi,
>
>
> The permissions are stored in the database and don't get translated.
>
> Refer: https://code.djangoproject.com/ticket/1688.
>
> poniedziałek, 10 maja 2021 o 19:35:38 UTC+2 M Vv napisał(a):
>
>> Translation of user permissions is not done.
>>
>> [image: gruop trans.PNG]
>>
>> How should it go about it?
>>
> -- 
> 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/da4f96c9-d780-4dde-8ae8-d6c7f0ef59b7n%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/c08b5352-1b13-4b47-9ead-04f590a6defdn%40googlegroups.com.

Re: Admin change list header for languages with grammatical cases

[Ramez Ashraf]

Thank you for bringing this up

Arabic is one of those language, the issue comes with masculine and 
feminine nouns.
" Select {model} to change"
If model noun is masculine then it's ok... if a feminine one then it's not 
correct.

Example: 
Correct أختر مقال لتغييره 
Wrong/awkward  اختر هيئه لتغييره 
should be اختر هيئه لتغييرها

i work around that by adding both .لتغييره(ها)
An other approach is change the text to 
Select {model} *record* to change
Because now change verb will be to a record which is a masculine noun 
regardless of the model.

Thanks for bringing this up again.

On Saturday, May 22, 2021 at 2:54:50 AM UTC+2 macie...@gmail.com wrote:

> I forgot to mention that my implementation extensively uses gettext 
> context functionality [1]. I am happy to comment on and discuss particular 
> parts of the implementation.
>
> The implementation is quite general, it does not limit the use of 
> attributes and contexts to only grammatical cases.
>
> I decided to use "*accusative*" for attribute and context name hoping 
> that all languages will use base verbose name case or accusative 
> grammatical case. But on the other hand context/attribute name "*changelist 
> title*" would be probably equally good (the former would be better, if 
> there would be more uses than in changelist title only).
>
> I think there comes natural expectation that similar mechanism would work 
> also in Django templates. That may be impossible because of dynamic nature 
> of this feature and serialization needed for safety and portability in 
> templates, although I'm not yet 100% sure.
>
> Regards,
> Maciej
>
> [1] 
> https://docs.djangoproject.com/en/3.2/topics/i18n/translation/#contextual-markers
>
> sob., 22 maj 2021 o 01:35 Maciek Olko  napisał(a):
>
>> Admin’s change list headers are “Select {model} to change”, “Select 
>> {model} to view” or “Select {model}” (for pop-ups). We inject model’s 
>> verbose name in that strings. It renders correct strings for most of the 
>> languages, but not for those, which have grammatical cases [1] for nouns. 
>> Such languages include Polish, Greek, Russian, Hungarian, Czech and many 
>> more.
>>
>> I try to track how many of languages are affected for selected nouns in a 
>> spreadsheet [2] with help of Google Translate.
>>
>> To make the headers correct for this languages we should inject a verbose 
>> name into “Select {}[…]” sentences in a correct grammatical case. 
>> Effectively it is usually a word with changed ending comparing to a base 
>> form of a noun (verbose name value).
>>
>> I’d like to propose a backwards compatible way to support an ability to 
>> provide a translation for a grammatical case of model’s verbose name and 
>> “selecting” to use it in a translation string.
>>
>> In short the implementation requires:
>>
>>- switching from %-string formatting to format-strings in admin’s 
>>changelist headers source strings,
>>- adding a class that will behave like string, but also let access 
>>it’s attributes,
>>- leveraging accessing attributes in Python format-string syntax.
>>
>> You can see here the implementation concluded in 7 commits: 
>> https://github.com/django/django/compare/main...m-aciek:accusative-in-admin-header-approach-2
>>
>> I don’t have enough means to confirm it for all languages, but my cursory 
>> research says that probably the case used in “Select {}” sentence is an 
>> *accusative* for all languages that have grammatical cases.
>>
>> I would like that feature to be in Django as currently the admin 
>> changelist header translation, with model name not inflected, in Polish 
>> (“Wybierz użytkownik do zmiany”) sounds awkwardly and incorrectly. I'd 
>> assume for other such languages the situation is similar. Bringing 
>> grammatical cases there would be a great step towards perfection (that 
>> should attract perfectionists :) ) in admin for languages like Czech, 
>> Greek, Hungarian and many more.
>>
>> I didn’t post a ticket nor created a pull request yet, as I’d like to 
>> consult it with the community beforehand, according to the best practices.
>>
>> Would you accept such a functionality in the Django project?
>>
>> Best regards,
>> Maciej Olko
>>
>> PS. There is a ticket about bringing gettext plurals into model’s verbose 
>> name [3] loosly connected with this particular topic, but the discussion 
>> underneath touches also the topic of grammatical cases.
>>
>> [1] https://en.wikipedia.org/wiki/Grammatical_case
>> [2] 
>> https://docs.google.com/spreadsheets/d/1GfdCMvqCdg1c2fTf940r8yEnCiXr9s86p0JbGRV4Aio
>> [3] https://code.djangoproject.com/ticket/11688
>>
>

-- 
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

Is it possible to disable verbose_name_plural if add_permission is False?

[al...@alexnewby.com]

If there is an inline admin, the inline_admin_formset verbose_name_plural 
is displayed even if add_permission is False and there are no existing 
objects.

https://github.com/django/django/blob/7ef2398e814e044d54b68359d473cc64902a8c31/django/contrib/admin/templates/admin/edit_inline/stacked.html#L10

Can it be disabled without overriding the form?

Thanks,

Alex

-- 
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/bcf38a37-96f7-487b-967e-c81a8e3aaaf7n%40googlegroups.com.

Re: Admin change list header for languages with grammatical cases

[Maciek Olko]

Thank you Ramez,

Could you confirm that grammatical case in Arabic in case of this sentence
("Select {}") it is an accusative (المنصوب)?

https://arabic.desert-sky.net/g_cases.html#acc

Kind regards,
Maciej

pon., 24 maj 2021 o 10:18 Ramez Ashraf  napisał(a):

> Thank you for bringing this up
>
> Arabic is one of those language, the issue comes with masculine and
> feminine nouns.
> " Select {model} to change"
> If model noun is masculine then it's ok... if a feminine one then it's not
> correct.
>
> Example:
> Correct أختر مقال لتغييره
> Wrong/awkward  اختر هيئه لتغييره
> should be اختر هيئه لتغييرها
>
> i work around that by adding both .لتغييره(ها)
> An other approach is change the text to
> Select {model} *record* to change
> Because now change verb will be to a record which is a masculine noun
> regardless of the model.
>
> Thanks for bringing this up again.
>
> On Saturday, May 22, 2021 at 2:54:50 AM UTC+2 macie...@gmail.com wrote:
>
>> I forgot to mention that my implementation extensively uses gettext
>> context functionality [1]. I am happy to comment on and discuss particular
>> parts of the implementation.
>>
>> The implementation is quite general, it does not limit the use of
>> attributes and contexts to only grammatical cases.
>>
>> I decided to use "*accusative*" for attribute and context name hoping
>> that all languages will use base verbose name case or accusative
>> grammatical case. But on the other hand context/attribute name "*changelist
>> title*" would be probably equally good (the former would be better, if
>> there would be more uses than in changelist title only).
>>
>> I think there comes natural expectation that similar mechanism would work
>> also in Django templates. That may be impossible because of dynamic nature
>> of this feature and serialization needed for safety and portability in
>> templates, although I'm not yet 100% sure.
>>
>> Regards,
>> Maciej
>>
>> [1]
>> https://docs.djangoproject.com/en/3.2/topics/i18n/translation/#contextual-markers
>>
>> sob., 22 maj 2021 o 01:35 Maciek Olko  napisał(a):
>>
>>> Admin’s change list headers are “Select {model} to change”, “Select
>>> {model} to view” or “Select {model}” (for pop-ups). We inject model’s
>>> verbose name in that strings. It renders correct strings for most of the
>>> languages, but not for those, which have grammatical cases [1] for nouns.
>>> Such languages include Polish, Greek, Russian, Hungarian, Czech and many
>>> more.
>>>
>>> I try to track how many of languages are affected for selected nouns in
>>> a spreadsheet [2] with help of Google Translate.
>>>
>>> To make the headers correct for this languages we should inject a
>>> verbose name into “Select {}[…]” sentences in a correct grammatical case.
>>> Effectively it is usually a word with changed ending comparing to a base
>>> form of a noun (verbose name value).
>>>
>>> I’d like to propose a backwards compatible way to support an ability to
>>> provide a translation for a grammatical case of model’s verbose name and
>>> “selecting” to use it in a translation string.
>>>
>>> In short the implementation requires:
>>>
>>>- switching from %-string formatting to format-strings in admin’s
>>>changelist headers source strings,
>>>- adding a class that will behave like string, but also let access
>>>it’s attributes,
>>>- leveraging accessing attributes in Python format-string syntax.
>>>
>>> You can see here the implementation concluded in 7 commits:
>>> https://github.com/django/django/compare/main...m-aciek:accusative-in-admin-header-approach-2
>>>
>>> I don’t have enough means to confirm it for all languages, but my
>>> cursory research says that probably the case used in “Select {}” sentence
>>> is an *accusative* for all languages that have grammatical cases.
>>>
>>> I would like that feature to be in Django as currently the admin
>>> changelist header translation, with model name not inflected, in Polish
>>> (“Wybierz użytkownik do zmiany”) sounds awkwardly and incorrectly. I'd
>>> assume for other such languages the situation is similar. Bringing
>>> grammatical cases there would be a great step towards perfection (that
>>> should attract perfectionists :) ) in admin for languages like Czech,
>>> Greek, Hungarian and many more.
>>>
>>> I didn’t post a ticket nor created a pull request yet, as I’d like to
>>> consult it with the community beforehand, according to the best practices.
>>>
>>> Would you accept such a functionality in the Django project?
>>>
>>> Best regards,
>>> Maciej Olko
>>>
>>> PS. There is a ticket about bringing gettext plurals into model’s
>>> verbose name [3] loosly connected with this particular topic, but the
>>> discussion underneath touches also the topic of grammatical cases.
>>>
>>> [1] https://en.wikipedia.org/wiki/Grammatical_case
>>> [2]
>>> https://docs.google.com/spreadsheets/d/1GfdCMvqCdg1c2fTf940r8yEnCiXr9s86p0JbGRV4Aio
>>> [3] https://code.djangoproject.com/ticket/11688
>>>
>> --
> You received this

Re: Admin change list header for languages with grammatical cases

[Ramez Ashraf]

Yep Confirm.

On Monday, May 24, 2021 at 10:52:15 PM UTC+2 macie...@gmail.com wrote:

> Thank you Ramez,
>
> Could you confirm that grammatical case in Arabic in case of this sentence 
> ("Select {}") it is an accusative (المنصوب)?
>
> https://arabic.desert-sky.net/g_cases.html#acc
>
> Kind regards,
> Maciej
>
> pon., 24 maj 2021 o 10:18 Ramez Ashraf  napisał(a):
>
>> Thank you for bringing this up
>>
>> Arabic is one of those language, the issue comes with masculine and 
>> feminine nouns.
>> " Select {model} to change"
>> If model noun is masculine then it's ok... if a feminine one then it's 
>> not correct.
>>
>> Example: 
>> Correct أختر مقال لتغييره 
>> Wrong/awkward  اختر هيئه لتغييره 
>> should be اختر هيئه لتغييرها
>>
>> i work around that by adding both .لتغييره(ها)
>> An other approach is change the text to 
>> Select {model} *record* to change
>> Because now change verb will be to a record which is a masculine noun 
>> regardless of the model.
>>
>> Thanks for bringing this up again.
>>
>> On Saturday, May 22, 2021 at 2:54:50 AM UTC+2 macie...@gmail.com wrote:
>>
>>> I forgot to mention that my implementation extensively uses gettext 
>>> context functionality [1]. I am happy to comment on and discuss particular 
>>> parts of the implementation.
>>>
>>> The implementation is quite general, it does not limit the use of 
>>> attributes and contexts to only grammatical cases.
>>>
>>> I decided to use "*accusative*" for attribute and context name hoping 
>>> that all languages will use base verbose name case or accusative 
>>> grammatical case. But on the other hand context/attribute name "*changelist 
>>> title*" would be probably equally good (the former would be better, if 
>>> there would be more uses than in changelist title only).
>>>
>>> I think there comes natural expectation that similar mechanism would 
>>> work also in Django templates. That may be impossible because of dynamic 
>>> nature of this feature and serialization needed for safety and portability 
>>> in templates, although I'm not yet 100% sure.
>>>
>>> Regards,
>>> Maciej
>>>
>>> [1] 
>>> https://docs.djangoproject.com/en/3.2/topics/i18n/translation/#contextual-markers
>>>
>>> sob., 22 maj 2021 o 01:35 Maciek Olko  napisał(a):
>>>
 Admin’s change list headers are “Select {model} to change”, “Select 
 {model} to view” or “Select {model}” (for pop-ups). We inject model’s 
 verbose name in that strings. It renders correct strings for most of the 
 languages, but not for those, which have grammatical cases [1] for nouns. 
 Such languages include Polish, Greek, Russian, Hungarian, Czech and many 
 more.

 I try to track how many of languages are affected for selected nouns in 
 a spreadsheet [2] with help of Google Translate.

 To make the headers correct for this languages we should inject a 
 verbose name into “Select {}[…]” sentences in a correct grammatical case. 
 Effectively it is usually a word with changed ending comparing to a base 
 form of a noun (verbose name value).

 I’d like to propose a backwards compatible way to support an ability to 
 provide a translation for a grammatical case of model’s verbose name and 
 “selecting” to use it in a translation string.

 In short the implementation requires:

- switching from %-string formatting to format-strings in admin’s 
changelist headers source strings,
- adding a class that will behave like string, but also let access 
it’s attributes,
- leveraging accessing attributes in Python format-string syntax.

 You can see here the implementation concluded in 7 commits: 
 https://github.com/django/django/compare/main...m-aciek:accusative-in-admin-header-approach-2

 I don’t have enough means to confirm it for all languages, but my 
 cursory research says that probably the case used in “Select {}” sentence 
 is an *accusative* for all languages that have grammatical cases.

 I would like that feature to be in Django as currently the admin 
 changelist header translation, with model name not inflected, in Polish 
 (“Wybierz użytkownik do zmiany”) sounds awkwardly and incorrectly. I'd 
 assume for other such languages the situation is similar. Bringing 
 grammatical cases there would be a great step towards perfection (that 
 should attract perfectionists :) ) in admin for languages like Czech, 
 Greek, Hungarian and many more.

 I didn’t post a ticket nor created a pull request yet, as I’d like to 
 consult it with the community beforehand, according to the best practices.

 Would you accept such a functionality in the Django project?

 Best regards,
 Maciej Olko

 PS. There is a ticket about bringing gettext plurals into model’s 
 verbose name [3] loosly connected with this particular topic, but the 
 discussion underneath touches also the topic of gram