[Feature request] Allow grammatical cases for verbose_names

[Maciek Olko]

Django calls itself a framework for perfectionists, whereas isn’t perfect
for locale Django admin in languages with grammatical cases. Please find a
description of an idea of one step towards perfection below.

PEP 3101  introduced compound
field names  in string
formatting for Python 2.7 and 3.2+. We can use it together with pgettext
 (gettext with context) to
allow use of grammatical cases in Django admin translation texts.

If Meta.verbose_name was object of class Noun, we could translate a title
of model changelist view from `Select {} to change` to e.g. (pl) `Wybierz
{.accusative} do zmiany` (correct grammatical case for Polish).

Verbose name definition in Group model needed would be:

verbose_name = Noun(pgettext(‘nominative’, ‘group’),
accusative=pgettext(‘accusative’, ‘group’))

For backward compatibility, we could wrap existing verbose_names behind the
scenes with Noun with only one grammatical case, and fallback all other
grammatical cases to first and standard case (covers also compatibility for
lack of translations for grammatical cases).

Before completing the feature I would try to figure out minimal set of
grammatical cases for Django admin and Django locale languages that uses
grammatical cases to enable use of those cases in translations strings.

AFAIK this change would involve a couple of changes in Django core, but can
be fully backward compatible.

I am willing to implement the solution myself, if only I will have enough
free time.

I would be very happy to receive any feedback.

Also feel free to supplement potential Django issue description for the
case:
https://docs.google.com/document/d/16uEnKyiO9mn66JI64RtmMrEY_fyG2tWbI7OZIFE880o/edit

Regards,
Maciej

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALYYG81wybpY7dJawEnwWOD7sj8PKSYbE-D2nzei2B014-syAg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Migration strategy for proxy model permissions to use their own content type

[Arthur Rio]

Thank you for your feedback Aymeric,

I have added the backward migration method + tests per your suggestion:
https://github.com/django/django/pull/10381/commits/d5c4a4b08ccee9239e5117df4c788a5a7a2f60a9

Regards


—
Arthur

On January 6, 2019 at 10:04:18 PM, Aymeric Augustin (
aymeric.augus...@polytechnique.org) wrote:

Hello Arthur,

I agree that option 1 is the way to go.

It would be nice to make the migration reversible. If someone upgrades to
Django 2.2.x, migrates the database, and later discovers a blocking issue,
they should have the option to migrate backwards and downgrade to 2.1.y.

Best regards,

-- 
Aymeric.



On 26 Nov 2018, at 16:10, Arthur Rio  wrote:

Hi all,

I have been working on a 9 years old ticket that I'd like to close once and
for all. The outstanding question is about the migration path to choose in
order to update existing proxy model permissions. I have explained three
different approaches I can think of in the pull request:
https://github.com/django/django/pull/10381#issuecomment-435534644.

I have implemented the first option and wrote the release notes explaining
what to expect for users upgrading:
https://github.com/django/django/pull/10381/files#diff-1f22a5c1d6164c6de8defb36f3829138
.

Carlton, who has been the main reviewer, suggested to contact the mailing
list for further review in order to catch any red flag and make sure we
have general consensus on the chosen approach.

Regards.

Arthur

--
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/f3298dbb-e072-4815-944c-2250d0b4d3a3%40googlegroups.com

.
For more options, visit https://groups.google.com/d/optout.


--
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/46CD821B-C17E-4FF8-B623-6B40B0FB0BBD%40polytechnique.org

.
For more options, visit https://groups.google.com/d/optout.

-- 
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 post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CADOBPEFozUMDawj%3DEi2Ju5eFnTFVzKR%2BYWw5VA0edJ%3DF2neirw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.