Hi Uri, As I understand it, the issue is around keeping this and all other PO files in the Django source updated and consistent in the future, since we rely on Transifex to provide them. Even if someone were to manually make the change you are suggesting, it would be overwritten the next time the files are updated from Transifex. I think this means the options are to (a) convince Transifex to revert the change or (b) help find a fix for ticket #30439.
If there is not a reason for the 3rd and 4th plural forms in Hebrew, perhaps Transifex would be willing to revert this change, I'm really not sure. But I would hazard a guess that they made the change for a reason, and that your energy would be best expended in helping to find a fix for #30439. This should also improve the behavior for *all* languages where the plural forms across PO files are not consistent. I'm not sure if they are watching this thread, but it looks like Rodrigo and Michal (?) were/are working on a fix in that ticket, and there is a branch open on one of their forks. Perhaps they could chime in if they see this, or you could reach out to them in the ticket or on GitHub to discuss and find a solution. Please remember that we are all volunteers, and rely on the work of fellow volunteers (like you!) to make Django the best that it can be. Thank you for following up about this issue, and good luck in tracking down a fix! Best, Tobias On Sat, Nov 23, 2019, 11:25 PM אורי <u...@speedy.net> wrote: > Hi, > > I was not aware that even Django have several .po files itself (for each > locale). I found out > https://github.com/django/django/blob/master/django/conf/locale/he/LC_MESSAGES/django.po > , > which has about 15 translations of 4 strings (plural forms), but even there > it seems to me that strings #1,2,3 are always the same, so there are only 2 > different strings (of plural forms) in each case. > > I don't know whether there are other .po files in Hebrew where maybe not > all the last 3 strings are the same. > > I kept searching and found > https://github.com/django/django/blob/master/django/contrib/humanize/locale/he/LC_MESSAGES/django.po > with > 40 such translations, with the same case as above, although in this file > there are translations which can and should be different, such as the > translation for "%d weeks" - strings #1,2,3 are identical ("%d שבועות") > even though there is a specific word for "2 weeks" in Hebrew ("שבועיים"), > which is better to use than the current translation. So I guess it's not > too late to reverse this setting at least for Hebrew, at least until > specific translations are made, maybe in Django 3.0 and above (or 3.1, 3.2) > and then maybe there will be an optional difference between the definition > of plural forms in each .po file, so it will not cause any damage to change > it back to 4 strings or even more then, without breaking current > functionality like what happens now. > > I apologize for the speakers of all other languages except Hebrew for not > understanding their language, and I also don't have time to look into > *any* locale. But at least in Hebrew, it seems to me that there is no > need in Django 2.2 for more than 2 plural forms (n==1, n!=1). And the > Django automatically relying on what is defined by Transifex is a mistake. > > > אורי > u...@speedy.net > > > On Sun, Nov 24, 2019 at 4:31 AM אורי <u...@speedy.net> wrote: > >> Hi, >> >> Please see my latest comment on this ticket: >> https://code.djangoproject.com/ticket/30439#comment:27 >> >> I would like to suggest, since I understand the problem is per locale, >> and I'm only familiar with the Hebrew (he) locale: Can you revert >> https://github.com/django/django/blob/master/django/contrib/auth/locale/he/LC_MESSAGES/django.po >> in >> Django 2.2 to use the plurals as they were defined in Django 2.1 ( >> https://github.com/django/django/blob/stable/2.1.x/django/contrib/auth/locale/he/LC_MESSAGES/django.po: >> "Plural-Forms: >> nplurals=2; plural=(n != 1);\n")? I checked the file and there are only 2 >> cases of msgstr[2] and msgstr[3] there, which are both identical >> to msgstr[1]. Will it break things in Hebrew? Will it break things in other >> locales? If people using other locales will ask, you can do similar things >> there too (if things are broken there in a similar way). I understand in >> some languages things were not broken like this in Django 2.2 (or other >> versions), and they used more plural forms there even before, so you don't >> have to change anything there. And in Django 3.0 (or whichever version you >> choose) you can make the .po files independent so they will not depend on >> each other, and the first .po file loaded will not influence the rest of >> the files. >> >> If you can revert such a change which was made, maybe even by mistake, in >> Django 2.2 and then fix the problem in Django 3.0 it may help not only >> Speedy Net but possibly anyone using Django with the Hebrew locale. You >> might not have made a deliberate decision to change Hebrew translation in >> Django 2.2, but it was changed from the change in the .po file from >> Transifex. But you (the Django developers) can make a deliberate decision >> to fix it. Or alternatively, if you fix the problem in Django 3.0 (or even >> 3.1 or 3.2) I might upgrade Speedy Net directly from 2.1 to 3.0 etc. >> without using 2.2 at all. But since 2.2 is an LTS version, I think you >> should make an effort to make it work, and therefore revert the >> plural-forms definition to the one used by Django 2.1. At least in Hebrew, >> but maybe in any language where it has changed. >> >> You might not have noticed this issue before because there are not many >> websites using these languages with Django, however for these websites this >> is a serious bug. I'm waiting for any solution to this problem before I >> upgrade to any Django version beyond 2.1. I even thought about forking >> Django and reverting this definition myself, but I prefer if Django itself >> will do it then for me forking Django. If I work Django I might not be able >> to apply all the changes you make in future releases, including security >> issues which might arise. >> >> Have you found any .po file of Django, in Hebrew, where the third and >> fourth strings are not identical to the second one? I'm currently not >> familiar with such a .po translation. >> >> אורי >> u...@speedy.net >> >> >> On Sun, Nov 24, 2019 at 2:50 AM Tobias McNulty <tob...@caktusgroup.com> >> wrote: >> >>> On Sat, Nov 23, 2019 at 9:17 AM אורי <u...@speedy.net> wrote: >>> >>>> By the way, I read here that this bug it the fault of Transifex (not >>>> Django). I'm not sure what that means, it worked in Django 2.1. Someone >>>> made a decision to change something in Django 2.2, how can it be Transifex? >>>> It must be a decision of the Django developers. If Transifex has bugs, why >>>> not use a previous version which worked? As far as I would suggest, I would >>>> postpone using the 4-strings translation (or up to 6 strings in some >>>> languages) to Django 5.0 or 10.0. Is it really that important to break all >>>> the 2-strings translations which worked? >>>> >>> >>> As far as I understand, the issue is the translations that are pulled in >>> from Transifex (it's not a version of Transifex that we can control). I >>> would hazard a guess that the same issue would occur with Django 2.1 if the >>> translations were updated; i.e., it's simply a matter of timing that it >>> happened to break with Django 2.2. >>> >>> There is some sample code in the ticket which might be good to try, to >>> see if it fixes the issue for you: >>> https://code.djangoproject.com/ticket/30439#comment:7 >>> >>> Cheers, >>> >>> >>> *Tobias McNulty*Chief Executive Officer >>> >>> tob...@caktusgroup.com >>> www.caktusgroup.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/CAMGFDKTM_uhYYC7R7oaADfK%3D_4kaMNjH5U8FQ1q%3DYVdutzpwEg%40mail.gmail.com >>> <https://groups.google.com/d/msgid/django-developers/CAMGFDKTM_uhYYC7R7oaADfK%3D_4kaMNjH5U8FQ1q%3DYVdutzpwEg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > 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/CABD5YeFrEqL-ksknPfyKggASH1WKwNX1i3AeKxVOzP38TuPS_w%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CABD5YeFrEqL-ksknPfyKggASH1WKwNX1i3AeKxVOzP38TuPS_w%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAMGFDKTdj4KL_P3kaft1e5hwA%3DYWGDs%3DojWNUJKb05GBw%3D2M5g%40mail.gmail.com.
