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 <maciej.o...@gmail.com> 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/CALYYG83gh1s6uBrXaM0eCBfz8MYKu5i6p3LRrUaq2-m85-X1Ww%40mail.gmail.com.

Reply via email to