Re: Admin login view does not respect REDIRECT_LOGIN_URL

[Maciek Olko]

Hello,

Please double check the setting name, it should be LOGIN_REDIRECT_URL
https://docs.djangoproject.com/en/4.2/ref/settings/#login-redirect-url.

Regards,
Maciej

wt., 17 paź 2023 o 05:35 Gagan Deep 
napisał(a):

> Hello everyone,
>
> While working on my project, I found that the admin login view does not
> respect the REDIRECT_LOGIN_URL
> .
> This could be design decision that I am overlooking (because admin is a
> special case?).
>
> In my limited time, I couldn't find a related discussion for this on
> Django's trac or GitHub repository (PRs). Hence, I wanted to confirm before
> opening a issue on trac.
>
> Regards,
> Gagan Deep
>
> --
> 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/6ead2cb4-c88f-4b4e-bd6c-a531491454cdn%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/CALYYG81Brg0QsioNMf-kVoTSw6VzaWPWxVyijGSnPTY4j-%3DJ-g%40mail.gmail.com.

Re: Feature Idea: Allow setting session cookie name dynamically

[Maciek Olko]

Ah, thank you for explaining. I missed the point and the existing setting,
sorry.

Cheers,
Maciej

wt., 7 cze 2022 o 11:26 Florian Apolloner 
napisał(a):

> Hi Maciej,
>
> You can already customize the cookie name via a setting. What this request
> is asking is customization based on the request object which is not that
> common. Did you check that you configured your applications correctly to
> use different cookie names (
> https://docs.djangoproject.com/en/4.0/ref/settings/#session-cookie-name)?
>
> > I wonder if using a Django project code name as part of session cookie
> for new projects would have a potential to be considered as an accepted
> feature.
>
> has not been considered (as far as I know) and is something I'd be
> strongly against.
>
> Cheers,
> Florian
>
> On Monday, June 6, 2022 at 11:51:24 PM UTC+2 macie...@gmail.com wrote:
>
>> Hi Dan and Carlton,
>>
>> In my current company I am impacted by conflicting session cookie name.
>> We have several internal tools built on Django, available in the internal
>> network under the same top-level domain. The scope of session cookies
>> apparently was set on more than one service to a wildcard. Majority of
>> users use only one of services in day-to-day work, so it's not impacting a
>> big number of people.
>>
>> I personally would be +1 for exposing a method to easily and without
>> copying much code one was able to change it.
>>
>> I wonder if using a Django project code name as part of session cookie
>> for new projects would have a potential to be considered as an accepted
>> feature.
>>
>> Kind regards,
>> Maciej
>>
>> pon., 6 cze 2022 o 22:19 Dan Strokirk  napisał(a):
>>
>>> Hi Carlton, thanks for the response.
>>>
>>> An external package might be useful, although the code majority of the
>>> code would be the copied SessionMiddleware code and the tiny changes to
>>> allow a dynamic cookie name, so my thoughts is that this might be "too
>>> small" for a published pypi package?
>>>
>>> But since I haven't found a similar request earlier on this mailing list
>>> or the issue tracker, it seems that it might be really niche, as you say!
>>>
>>> Best regards,
>>> Dan
>>>
>>> --
>>> 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/01a91019-8d54-4322-a295-dbfdc12dfab9n%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/08a438ff-9d7a-47e0-abe2-d68a7dd20935n%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/CALYYG80d1ngzzxCOJs3-M494BGLssVGRMgmQEUWopFGeXXghoQ%40mail.gmail.com.

Re: Feature Idea: Allow setting session cookie name dynamically

[Maciek Olko]

Hi Dan and Carlton,

In my current company I am impacted by conflicting session cookie name. We
have several internal tools built on Django, available in the internal
network under the same top-level domain. The scope of session cookies
apparently was set on more than one service to a wildcard. Majority of
users use only one of services in day-to-day work, so it's not impacting a
big number of people.

I personally would be +1 for exposing a method to easily and without
copying much code one was able to change it.

I wonder if using a Django project code name as part of session cookie for
new projects would have a potential to be considered as an accepted feature.

Kind regards,
Maciej

pon., 6 cze 2022 o 22:19 Dan Strokirk  napisał(a):

> Hi Carlton, thanks for the response.
>
> An external package might be useful, although the code majority of the
> code would be the copied SessionMiddleware code and the tiny changes to
> allow a dynamic cookie name, so my thoughts is that this might be "too
> small" for a published pypi package?
>
> But since I haven't found a similar request earlier on this mailing list
> or the issue tracker, it seems that it might be really niche, as you say!
>
> Best regards,
> Dan
>
> --
> 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/01a91019-8d54-4322-a295-dbfdc12dfab9n%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/CALYYG81HK-M2erdz4j5Jtp3h8J3vOaPj-qvE7rMPFRNiqKY1uA%40mail.gmail.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,

Re: Admin change list header for languages with grammatical cases

[Maciek Olko]

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

Admin change list header for languages with grammatical cases

[Maciek Olko]

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/CALYYG838Fv1DvY3o7M84z-%3DfKnFQr0JHyc1N7XHjjPBf_UcQbA%40mail.gmail.com.

Re: ngettext_lazy and ngettext

[Maciek Olko]

Hi,
I am wondering if Django shouldn't use Unicode Plural Rules as standard and
promote it for third-party apps. Even if sometimes number of forms are not
applicable to certain cases, there may be cases when all of forms will be
needed.

Especially if implementing having different plural rules for various apps
is not trivial.

For the record, here is a section of Transifex documentation that describes
their statement about plural rules and Unicode standard:
https://docs.transifex.com/localization-tips-workflows/plurals-and-genders#how-pluralized-strings-are-handled-by-transifex
.

Regards,
Maciej

czw., 5 gru 2019 o 08:00 Matemática A3K 
napisał(a):

> While testing the "not-merging" policy, I got this:
> https://pastebin.com/ihyAiYtc
> Those warnings should get to the Translators teams if they are not looking
> here, i.e.
>
> https://github.com/django/django/blob/master/django/contrib/sessions/locale/he/LC_MESSAGES/django.po
> is still using a 2-plurals form in a 4 plural form - it doesn't matter in
> this case because there are no translations with plurals, but they trigger
> the warning because the pf hasn't been updated and they should if the
> Transifex front-end use the pf of a file for showing the options for
> translating and to be inline with the main form.
>
>
> On Thu, Dec 5, 2019 at 12:10 AM Matemática A3K 
> wrote:
>
>>
>>
>> On Wed, Dec 4, 2019 at 2:25 AM Claude Paroz  wrote:
>>
>>> Le mercredi 4 décembre 2019 03:41:51 UTC+1, Matemática A3K a écrit :

 (...)

 But, then I realized that there is major caveat on this approach, and
 that is that updates on the plural equation won't reach users' catalogs,
 because their catalogs will be kept separately one the plural form differs.
 This would be the case that Shai pointed on Django 2.2 with the incorrect
 plural equation for HE. People who have generated their catalogs with
 makemessages on 2.2 will have a wrong plural equation, that once it is
 fixed on a new release, it won't reach their catalogs because they will be
 kept apart.

>>>
>>> Sorry, I'm not following you here. The catalog merge process is
>>> happening in realtime when Django starts, so any po file update is
>>> instantly reflected in the translation infrastructure. I don't see any
>>> caveat here.
>>>
>>
>> Yes, but only for the default language, the rest are lazily loaded on
>> demand - this is why I think it is better do the check at a system level,
>> if you have more than a language available, the others will be merged for
>> loading them once something triggers it (like an
>> "activate("LANGUAGE_CODE")) and only there you would start to see the
>> warnings.
>>
>> For the example of the caveat of the dict-merging, it would be like this:
>>
>> - Someone starts its translation with Django 2.2 for Hebrew via
>> makemessages, which copies the main plural form to the new file, and fills
>> the translations.
>> - The user upgrades to Django 2.2.x or up, which contains a fixed plural
>> form for Hebrew
>> - Under the "dict-merge" policy, the Django translation catalog would
>> have 2 entries, one for the main plural form (the new one) and other the
>> catalog generated in the past (the user's one).
>>
>> Strings in the user catalog would use a "worse" plural equation, while
>> strings in the Django catalog will use the better one. Updates won't reach
>> to users' catalogs, unless they explicitly update them, because once the
>> user's po is created, makemessages won't update the header, it will do a
>> msgmerge (
>> https://github.com/django/django/blob/master/django/core/management/commands/makemessages.py#L603
>> ).
>>
>> That's why something like "makemessages --update-plural-form" and a
>> warning about different plurals forms in the catalog would be needed, even
>> under "dict-merge".
>>
>> With the current "merge" policy, because only the main form used, the
>> users would get the update but they won't be able to have parts of the
>> catalog under a different pf.
>>
>> The way to have a different plural form than the main one with the
>> current code base would be by having a custom variant of the language
>> (which implements "the spirit of dict-merge": independent catalogs with an
>> order of precedence). It's not ideal, you will loose the ability of using
>> the browser's locale config to display the language out of the box unless
>> you add extra code to handle it, something like "if locale == 'he': use
>> 'he_SP'" (no other caveat comes to my mind). But it would be they way of
>> having it RN without loosing the updates.
>>
>>
>>>
>>> Claude
>>>
>>> --
>>> 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
>>> 

Re: ngettext_lazy and ngettext

[Maciek Olko]

Hi Uri,

Regarding your past questions,

If you want I can try to spend some time to help solving this specific
> problem. I would start with documenting this issue in the release notes of
> Django 2.2. I already opened a new task #30945
> <https://code.djangoproject.com/ticket/30945> for documenting this issue.
> How do I proceed from here? I think I never submitted changes directly to
> Django Git & documentation. Where are the source code of the release notes
> documentation and how do I change them?


I think that following articles might be helpful:
* Writing documentation [1],
* Submitting patches [2].

Source file for 2.2 release notes is docs/releases/2.2.txt [3].

Regards,
Maciej

[1]
https://docs.djangoproject.com/en/stable/internals/contributing/writing-documentation/
[2]
https://docs.djangoproject.com/en/stable/internals/contributing/writing-code/submitting-patches/
[3] https://github.com/django/django/blob/master/docs/releases/2.2.txt

‪wt., 26 lis 2019 o 13:55 ‫אורי‬‎  napisał(a):‬

> Hi Maciej,
>
> I would not say the rules are incorrect. It depends on the case. In some
> cases they might be correct and there might be 3, 4 or even more plural
> forms. But in many other cases, two plural forms are enough. It depends on
> the strings being translated. I think in most cases, two plural forms are
> correct, like was in Django up to 2.1.
>
> For example in weeks, there is a word in hebrew for "two weeks"
> ("שבועיים"), which is more correct than writing two words for two weeks ("2
> שבועות"). But in other cases, there is not a specific word for "2
> ". In the case of Speedy Net for example, I used
> function ngettext_lazy in a validator validating the number of characters
> in a password or username. In these cases, only the plain plural form
> should be used, and anyway the number given there is probable not 1 and
> also not 2. It might be in some specific cases 6, 8 or 120, and there is no
> specific plural form for that number of characters. The translation is just
> using the Hebrew word for characters ("תווים"). Even if this number was 2,
> it would have used the same word, but there is a singular word for 1.
>
> אורי
> u...@speedy.net
>
>
> On Tue, Nov 26, 2019 at 1:29 PM Maciek Olko  wrote:
>
>> It looks like Transifex uses [1] Unicode Language Plural Rules [2]. If
>> they are incorrect for Hebrew, maybe they should be fixed on Unicode side?
>>
>> Regards,
>> Maciej
>>
>> [1]
>> https://community.transifex.com/t/where-does-the-5-come-from-in-the-json-export-of-pluralized-strings/1389/2?u=m-aciek
>> [2]
>> http://www.unicode.org/cldr/charts/latest/supplemental/language_plural_rules.html
>>
>> ‪wt., 26 lis 2019 o 08:18 ‫אורי‬‎  napisał(a):‬
>>
>>>
>>>
>>> On Tue, Nov 26, 2019 at 8:13 AM Matemática A3K 
>>> wrote:
>>>
>>>>
>>>>
>>>> ‪On Mon, Nov 25, 2019 at 6:26 AM ‫אורי‬‎  wrote:‬
>>>>
>>>>>
>>>>> אורי,
>>>>
>>>> OK, have in mind that a change of the number of plurals for a language
>>>> is kind (if not) of an API change for i18n - now you have to feed a
>>>> different input - and should be handled as such. There is no way of
>>>> modifying your code on an upgrade by the software distribution (the
>>>> package).
>>>>
>>>> Did the script that I posted not do the job?
>>>>
>>>
>>> No offense, but I didn't try. As a Django user I don't expect Django to
>>> send me to install and run third party scripts that will keep my sites
>>> working when I upgrade Django. I also don't think there is need for 4
>>> plural forms in my .po files. I would like to keep using 2 plural forms as
>>> that makes more sense to me.
>>>
>>> I decided to keep using Django 2.1.
>>>
>>> --
>>> 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/CABD5YeH%3DwqNcWsu5_Lzab39qmcDPY%2BymGD2k-R1mbr%3DEiCvbnQ%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/django-developers/CABD5YeH%3DwqNcWsu5_Lzab39qmcDPY%2BymGD2k-R1mbr%3DEiCvbnQ%40mail.gmail.com?utm_medium=email_source=footer>
>>> .
>>>
>> --
>> You received this message because you are subscr

Re: ngettext_lazy and ngettext

[Maciek Olko]

It looks like Transifex uses [1] Unicode Language Plural Rules [2]. If they
are incorrect for Hebrew, maybe they should be fixed on Unicode side?

Regards,
Maciej

[1]
https://community.transifex.com/t/where-does-the-5-come-from-in-the-json-export-of-pluralized-strings/1389/2?u=m-aciek
[2]
http://www.unicode.org/cldr/charts/latest/supplemental/language_plural_rules.html

‪wt., 26 lis 2019 o 08:18 ‫אורי‬‎  napisał(a):‬

>
>
> On Tue, Nov 26, 2019 at 8:13 AM Matemática A3K 
> wrote:
>
>>
>>
>> ‪On Mon, Nov 25, 2019 at 6:26 AM ‫אורי‬‎  wrote:‬
>>
>>>
>>> אורי,
>>
>> OK, have in mind that a change of the number of plurals for a language is
>> kind (if not) of an API change for i18n - now you have to feed a different
>> input - and should be handled as such. There is no way of modifying your
>> code on an upgrade by the software distribution (the package).
>>
>> Did the script that I posted not do the job?
>>
>
> No offense, but I didn't try. As a Django user I don't expect Django to
> send me to install and run third party scripts that will keep my sites
> working when I upgrade Django. I also don't think there is need for 4
> plural forms in my .po files. I would like to keep using 2 plural forms as
> that makes more sense to me.
>
> I decided to keep using Django 2.1.
>
> --
> 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/CABD5YeH%3DwqNcWsu5_Lzab39qmcDPY%2BymGD2k-R1mbr%3DEiCvbnQ%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/CALYYG818kvK%3DPRxj1C_DS-xB5tKkS2zFiBUL02AT5xyWvUNHLw%40mail.gmail.com.

Re: Extend FAQ with "How do I get Django and my JS framework to work together?"

[Maciek Olko]

Thank you all for all your responses!

It's been a long time (sorry!), but:
* I've added a Django ticket considering topic discussed here. [1]
(* I updated a bit AJAX Django wiki page. [2])

Aymeric, in terms of copyright ownership, would you agree on rephrasing
fragments of your articles to put it into Django docs?

Regards,
Maciej

[1] https://code.djangoproject.com/ticket/30296
[2] https://code.djangoproject.com/wiki/AJAX

śr., 27 lut 2019 o 15:37 użytkownik Jamesie Pic  napisał:

> FTR I published my own writeup here:
> https://blog.yourlabs.org/post/183077442308/django-js-research-report
>
> --
> 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/CAC6Op184WMaf09CD1NqznfCQv%2BqhcMePB8nUdTKpTns1Fejc0A%40mail.gmail.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/CALYYG80eYMHMqis10UpxsehTdQRObxKP5c7c%2Bfr9TF6fLdxTwA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Extend FAQ with "How do I get Django and my JS framework to work together?"

[Maciek Olko]

I didn't find this topic being discussed before.

It seems to me to be good idea to place "How do I get Django and my JS
framework to work together?" or similar question and answer to it in FAQ in
Django's docs.

Having very big popularity of JS frameworks now it is indeed very common
question being asked or searched on the Internet. Such question for ReactJS
has 65k views on StackOverflow [1].

The answer could briefly explain that one can make use of Django backend
and produce API to be consumed by JS clients. Probably it would be good to
link to Django REST API project as a suggestion for big projects.

What do you think about such addition to FAQ?

Regards,
Maciej

[1]
https://stackoverflow.com/questions/41867055/how-to-get-django-and-reactjs-to-work-together

-- 
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/CALYYG81uHehznRBvR4obTZr8685u0nm9y7yeUykPx8j0%3DJ-GyA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Add support for filter arguments in queryset.exists() and queryset.count()

[Maciek Olko]

Dear Sjoerd, dear all,

My thoughts:
* on one hand it feels natural to simplify calls and keep things simple,
from this perspective +1;
* on the other I can imagine new Django user that gets confused by
inconsistency in code snippets or StackOverflow: you can now filter not
only using filter() or get() methods, from this perspective -1;
* get() already supports field lookups, so count() and exists() would join
it to stand in one row, from this perspective +1;
* if introducing such change, for sure documentation should be very
carefully reviewed and updated to mirror the new preferred way of doing
count and exists queries;
* it would be quite a big change, I think it should be introduced with
preferably MAJOR or at least MINOR version of Django;
* maybe an e-mail encouraging community to update e.g. StackOverflow with
new Django syntaxt sections after the release to avoid confusion for
newcomers would be a good idea?;
* what about first() and delete()? (rest of queryset methods with no
arguments, that doesn't return a queryset); should they also support field
lookups?
* what about reverse() and all()? (rest of queryset methods with no
arguments that return a queryset); should they also support field lookups?

Kind regards,
Maciej Olko

pt., 18 sty 2019 o 22:12 użytkownik Sjoerd Job Postmus 
napisał:

> Dear all,
>
>
> This is probably a feature that has been proposed before, but I could
> not find a discussion on it, so I proposed it on the tracker, and Tim
> also couldn't find a discussion.
>
> (ticket: https://code.djangoproject.com/ticket/30118 )
>
> I would like to propose being able to write
> `SomeModel.objects.exists(field=value)` over
> `SomeModel.objects.filter(field=value).exists()` (and similar for
> `.count(**kwargs)`.
>
>
> As Tim rightfully commented: "There should be one-- and preferably only
> one --obvious way to do it.".
>
>
> I'm proposing this is a case where the obvious way would eventually be
> more in line with my suggestion instead of what we currently use.
>
>
> Consider the following code example (from
>
> https://github.com/django/django/blob/709a8b861de14204f0e13c9a0fbfd61c11b3565d/tests/auth_tests/test_management.py#L998
> ):
>
>
>  Permission.objects.filter(
>  content_type__model=opts.model_name,
>  content_type__app_label=opts.app_label,
>  codename=codename,
>  ).exists()
>
> There is a weird (to me, your mileage might vary) ").exists()" as a
> final line, and I would like to write this as
>
>  Permission.objects.exists(
>  content_type__model=opts.model_name,
>  content_type__app_label=opts.app_label,
>  codename=codename,
>  )
>
> This pattern seems to be quite rare in the Django codebase itself, but
> in the codebase at work we have several cases of `queryset.filter( of lines>).exists()` (and similar with count), and I am expecting this
> to also be prevalent in other codebases out there.
>
>
> Arguing against it however are the following lines of the Zen of Python:
>
> - "Explicit is better than implicit."
>
> - Maybe also "Special cases aren't special enough to break the rules.",
> because `.filter().count()` and `.exclude().count()` are both the same
> pattern, but this would only create an alternative for the first.
>
> - "There should be one-- and preferably only one --obvious way to do it."
>
>
> Beyond these short quips, I was hoping there might also be an earlier
> discussion covering this.
>
>
> Kind regards,
>
> Sjoerd Job Postmus
>
> --
> 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/63f21e13-4c6e-89f2-aca3-6961e98832df%40sjec.nl
> .
> 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/CALYYG83gUsf7uc-w8_hUVKYxd_i%3DPshguRB4VLrA-c4g2k9R6g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: What do you think about unify templates feature?

[Maciek Olko]

Did you try to measure the difference in time of rendering standard and
your way?

Regards,
Maciej

czw., 17.01.2019, 10:02 użytkownik J. Pablo Martín Cobos 
napisał:

> Hi,
>
> From one year ago, I am using an own command for Django templates that
> unify them. With an example it is easy to see. If I am to render for
> example a template call news.html like it:
>
> 1. news.html
>
> {% extends "base.html" %}
>
> {% block title %}
> {% include "inc.news.title.html" %}
> {% endblock %}
>
> {% block content %}
> {% for news_item in news %}
> {{ news_item.title }}
> {{ news_item.subtitle }}
> {% endfor %}
> {% endblock %}
>
> 2. base.html
>
>  http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
> http://www.w3.org/1999/xhtml; lang="{{
> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
> %}>
> 
> {% block title %}{% endblock %}
> 
> 
> {% block content %}{% endblock %}
> 
> 
>
> 3. inc.news.title.html
> News
>
> With this command I preproces every template of a settings variable and I
> get something like this:
>
> news.unify.html
>
>  http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd;>
> http://www.w3.org/1999/xhtml; lang="{{
> LANGUAGE_CODE|default:"en-us" }}" {% if LANGUAGE_BIDI %}dir="rtl"{% endif
> %}>
> 
> News
> 
> 
> {% for news_item in news %}
> {{ news_item.title }}
> {{ news_item.subtitle }}
> {% endfor %}
> 
> 
>
> So I have a two improves:
>
>1. It is more fast. And in a real project a view can render easyly 50
>templates
>2. I use news.html to develop and news.unify.html to production. So I
>don't lose legilibility.
>
>
> What do you think about "unify templates feature"? Do you know if exists a
> similar public project in github/gitlab/bitbucket etc?
>
>
> Best,
>
> --
> Pablo Martín Cobos
> Computer engineer
> Python/Django developer
> 652 53 37 36
> goi...@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 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/CALNyWLGNcuK8DTnU9w9fyGFhFfT3dAz7vfj3B%2BnDHWTfneLNFw%40mail.gmail.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/CALYYG805GZFJL5b_9nortw8Sj%2Bkrx1p4xqki7C96Zd8vHeYsmw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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