ngettext_lazy and ngettext
Django developers, I opened ticket https://code.djangoproject.com/ticket/30939 and I was referred to https://code.djangoproject.com/ticket/30439 as a duplicate. I don't understand why you need such a long formula to decide if a number is singular or plural. If it's 1 it's singular, otherwise it's plural. What's wrong about that? If you want to define a function with 4 strings for 4 different numbers, you should define a new function and not edit ngettext_lazy and ngettext. My code which works with all Django versions up to 2.1, breaks with Django 2.2. This issue prevents me from upgrading Django to 2.2. Is this change documented in the release notes? I didn't find it there. I would like to keep using ngettext_lazy with 2 strings (when the number is either 1 or not 1) and not with 4 strings. Actually I always use plural but because similar validators used ngettext_lazy (MinLengthValidator and MaxLengthValidator in django.core.validators) I also used it in my validators. But the number I'm using is never equal to 1. You can see my code here (search for "ngettext_lazy"): https://github.com/speedy-net/speedy-net/blob/master/speedy/core/accounts/validators.py And the relevant Django code: https://github.com/django/django/blob/master/django/core/validators.py#L348-L377 אורי u...@speedy.net -- 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/CABD5YeG8A%2BfLNom1BrOogYKpfOpfrCxK32OT%3D1dMO-cPyaL9sw%40mail.gmail.com.
Re: ngettext_lazy and ngettext
Hi, I want to add that it was very simple to upgrade Django from 1.11 to 2.0 and then to 2.1, I only had to change minor changes in my code - changing to class-based views and updating my tests to reflect the 403 pages (instead of a 302 redirect), so thanks for maintaining Django and for not breaking too many things when upgrading Django from one version to another. I hope you will agree to revert the changes done to ngettext_lazy and ngettext in version 2.2 and then I will be able to upgrade Django to the next LTS version. אורי u...@speedy.net On Fri, Nov 1, 2019 at 10:18 AM אורי wrote: > Django developers, > > I opened ticket https://code.djangoproject.com/ticket/30939 and I was > referred to https://code.djangoproject.com/ticket/30439 as a duplicate. I > don't understand why you need such a long formula to decide if a number is > singular or plural. If it's 1 it's singular, otherwise it's plural. What's > wrong about that? > > If you want to define a function with 4 strings for 4 different numbers, > you should define a new function and not edit ngettext_lazy and ngettext. > My code which works with all Django versions up to 2.1, breaks with Django > 2.2. This issue prevents me from upgrading Django to 2.2. Is this change > documented in the release notes? I didn't find it there. I would like to > keep using ngettext_lazy with 2 strings (when the number is either 1 or not > 1) and not with 4 strings. Actually I always use plural but because similar > validators used ngettext_lazy (MinLengthValidator and MaxLengthValidator in > django.core.validators) I also used it in my validators. But the number I'm > using is never equal to 1. > > You can see my code here (search for "ngettext_lazy"): > > https://github.com/speedy-net/speedy-net/blob/master/speedy/core/accounts/validators.py > > > And the relevant Django code: > > https://github.com/django/django/blob/master/django/core/validators.py#L348-L377 > > > אורי > u...@speedy.net > -- 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/CABD5YeGzsMT3D0JHcH-bEaS0YZm2kY%3DVHTRngDUq3Q%3D640jgLg%40mail.gmail.com.
Re: ngettext_lazy and ngettext
Hi Uri, I think you did not understand well the problem. Let me try to explain it in more details. Nothing was changed with "ngettext" or "ngettext_lazy" in Django. The plural equation for Hebrew was changed on the Transifex platform and those changes reach Django each time we synchronize translations with Transifex (a script-driven process). Note that it was the case for some other languages too. The plural equation defines how many different plural forms can exist for any language. English has two, Arabic has six, etc. Apparently, someone discovered/decided that Hebrew can have 4 different plurals in certain cases, that's probably why Transifex changed it, but I cannot tell you more about the rationales. By reading the new Hebrew equation, it looks like the plural can be different if the number is 1, 2, (20, 30, 40, etc.), or anything else. The problem with Django, which is the object of #30439, is that Django is using only the plural equation of the core django.po file, so if you have several .po files with different plural equations, the plural may be wrong or can fallback to English. Typically in your case, the core Django po file has an equation with 4 plurals, while your Speedy.net po file has only 2, so when the translation infrastruction is looking for the 3rd or 4th form, it finds nothing and return the English string. You should be able to fix that by re-doing a makemessages in your project in a Django 2.2 environment, and you should find that your updated po file will have 4 plurals for each plural string (but then running your project with older Django versions can have translation problems again :-( ). Hopefully someone will have the time to prepare a patch to solve #30429 in order that plural string changes can be easily managed. Regards, Claude t > -- 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/9d8ade17-3d6e-46dc-8ad7-a6b27de90593%40googlegroups.com.
Re: Fellow Reports -- October 2019
Hi all. Calendar Week 44 -- ending 03 November. Triaged: https://code.djangoproject.com/ticket/30937 -- URLField validator (URLValidator) does not respect null/blank (needsinfo) https://code.djangoproject.com/ticket/30931 -- Cannot override get_FOO_display() in Django 2.2+. (Accepted) https://code.djangoproject.com/ticket/30917 -- Clarify Formset documentation. (Accepted) https://code.djangoproject.com/ticket/30922 -- Admin's date_hierarchy excludes 31 october when using timezone with DST in northern hemisphere. (Duplicate of 29724.) https://code.djangoproject.com/ticket/30924 -- Numbers in top-level domain raise ValidationError (wontfix) Reviewed: https://code.djangoproject.com/ticket/17007 -- Fixture documentation should include non-numeric PK information https://github.com/django/django/pull/12000 -- Refs #30095 -- Simplified Field._check_choices() a bit. https://github.com/django/django/pull/11997 -- Fixed #30761 -- Prevented floatformat filter from returning a negative zero. https://github.com/django/django/pull/11942 -- Fixed #20456 -- Added CBV Testing docs https://github.com/django/django/pull/11908 -- Refs #20456 -- Moved initialization of HEAD method based on GET to the View.setup() for generic views. https://github.com/django/django/pull/11948 -- Fixed #30828 -- Added docs for bulk adding/removing many-to-many relationships https://github.com/django/django/pull/11899 -- Fixed #30828 -- Added add_relations and remove_relations. https://github.com/django/django/pull/11975 -- Fixed #13750 -- Clarified need to reopen models.ImageField.image file to access raw image data. https://github.com/django/django/pull/11973 -- Fixed #30910 -- Added system check to warn on duplicate check constraints. https://github.com/django/django/pull/11980 -- Fixed #30917 -- Clarifed Formsets topic documentation. Authored: https://github.com/django/django/pull/11999 -- Fixed #30931 -- Restored ability to override Model.get_FIELD_display(). Kind Regards, Carlton -- 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/b1f9f085-2654-4f1b-8840-2035d355e238%40googlegroups.com.
Re: ngettext_lazy and ngettext
Hi Claude, Thanks for the explanation, I understand the problem better now. I was not aware that the number of singular and plural forms depends on the language. I would like to clarify a few things: 1. Some of the strings used by "ngettext" or "ngettext_lazy" are unique to Speedy Net, some are not. Anyway I added translations for all of them in the Speedy Net django.po files, for the case that if Django will change the strings, they will still be translated. 2. When running ./make_all_messages.sh in Django 2.2, which runs make_messages for the locales en and he, nothing changes in the django.po files (except the date) - a third and fourth line are not added. 3. I think Django should handle django.po files when there are only 2 forms - singular and plural - and use the same plural forms for all forms of plurals, whatever that means. And in many cases the plural forms are identical, as I found out for example in https://github.com/django/django/blob/master/django/contrib/auth/locale/he/LC_MESSAGES/django.po#L223-L233. Actually from my knowledge of Hebrew, in most cases the plural form is the same for all numbers. In my case for example, Speedy Net, I only use plural although the singular is defined. I just copied the definition from Django validators with "ngettext_lazy" included. So I think there should be a fallback, so if only 2 forms are defined - singular and plural - then Django should use the same plural form for all plurals. This will also provide a backward compatibility to previous versions of Django. 4. Everything worked for me with Django versions up to 2.1. I think if such a big change is introduced to Django, which is not backward compatible, then new functions should be introduced by leaving "ngettext" or "ngettext_lazy" as they are. Or at least there should be some setting to allow backward compatibility. Especially since updating the django.po files might cause problems when downgrading to previous versions of Django, which don't support it. 5. If running make_messages will introduce 2 more plural forms in the django.po files, I expect the new forms to default to the plural form currently defined, to allow backward compatibility. And also, these functions should work when downgrading to a previous version of Django. 6. I never used Transifex directly. I only use Django. I never even heard about Transifex until today. Django developers can do whatever they want with third party dependencies. What matters to me is how Django works. Thanks, אורי u...@speedy.net On Fri, Nov 1, 2019 at 9:29 PM Claude Paroz wrote: > Hi Uri, > > I think you did not understand well the problem. Let me try to explain it > in more details. > > Nothing was changed with "ngettext" or "ngettext_lazy" in Django. The > plural equation for Hebrew was changed on the Transifex platform and those > changes reach Django each time we synchronize translations with Transifex > (a script-driven process). Note that it was the case for some other > languages too. > > The plural equation defines how many different plural forms can exist for > any language. English has two, Arabic has six, etc. > Apparently, someone discovered/decided that Hebrew can have 4 different > plurals in certain cases, that's probably why Transifex changed it, but I > cannot tell you more about the rationales. By reading the new Hebrew > equation, it looks like the plural can be different if the number is 1, 2, > (20, 30, 40, etc.), or anything else. > > The problem with Django, which is the object of #30439, is that Django is > using only the plural equation of the core django.po file, so if you have > several .po files with different plural equations, the plural may be wrong > or can fallback to English. Typically in your case, the core Django po file > has an equation with 4 plurals, while your Speedy.net po file has only 2, > so when the translation infrastruction is looking for the 3rd or 4th form, > it finds nothing and return the English string. You should be able to fix > that by re-doing a makemessages in your project in a Django 2.2 > environment, and you should find that your updated po file will have 4 > plurals for each plural string (but then running your project with older > Django versions can have translation problems again :-( ). > > Hopefully someone will have the time to prepare a patch to solve #30429 in > order that plural string changes can be easily managed. > > Regards, > > Claude > > t > >> -- > 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/9d8ade17-3d6e-46dc-8ad7-a6b27de90593%40googlegroups.com >
Re: ngettext_lazy and ngettext
Hi, I checked and I didn't find anything related to this issue documented on the Django 2.2 release notes. Is it documented? אורי u...@speedy.net -- 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/CABD5YeE6M89GTd-Tcn09NK3xBrqCmz5zJC040q-FE5TKT8W1dg%40mail.gmail.com.
