Hi, I tried to join the Django team on Transifex about 3 weeks ago (for Hebrew) but I failed. I think there may be a better translation using 4 plural forms in Hebrew or even more, however with the current situation of Django 2.2 translation to Hebrew it seems to me that the last 2 strings are never used (they are always identical to string #1). I'm not sure how Transifex works, since they didn't let me join the team, but if there is an option to reverse this setting in Django 2.2 and possibly 3.0, while keeping the option of more plural forms in future versions, after #30439 is fixed, this may be a good solution. But I'm not sure how to do it with Transifex, I don't know if they have branch names and versions like Django.
If #30439 is fixed in Django 3.0 or 3.1 (which I expect), I might have to upgrade to this version directly without using 2.2 at all. This is a shame since 2.2 should be LTS and I actually wanted to upgrade to 2.2 this month (from 1.11), and wait until the next LTS before upgrading Django again. But will a fix of #30439 be applied to Django 2.2? If a fix is applied also to 2.2 it may solve this problem for me. Claude Paroz said it will not happen in Django 2.2 [https://code.djangoproject.com/ticket/30439#comment:26]. אורי u...@speedy.net On Sun, Nov 24, 2019 at 6:37 AM Tobias McNulty <tob...@caktusgroup.com> wrote: > 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 > <https://groups.google.com/d/msgid/django-developers/CAMGFDKTdj4KL_P3kaft1e5hwA%3DYWGDs%3DojWNUJKb05GBw%3D2M5g%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/CABD5YeHDLvNTOvbNezkoN%3DOJU67j6pW%2BjOJLcscy5VdV41wz%3Dw%40mail.gmail.com.
