Hi Matemática, I prefer to keep using Django 2.1 until there is a solution that doesn't require so much effort from me when upgrading. I currently don't think we need 4 strings (plural forms) in our project's .po files and anyway I don't want to change them manually, only if they are changed automatically when I upgrade Django. My websites are currently working properly (as far as I know) with Django 2.1 and I want to keep it this way.
If a solution is made but applied to Django 3.0 or 3.1, I might decide to upgrade directly from 2.1 to 3.0 or 3.1, without using Django 2.2. אורי u...@speedy.net On Mon, Nov 25, 2019 at 1:40 AM Matemática A3K <matematica....@gmail.com> wrote: > ,אורי > Follow the instructions here if you want to change the plural form for > your django project "temporarily": > https://code.djangoproject.com/ticket/30439#comment:17 > > Maintaining several catalogs unmerged can lead to inconsistencies also if > you don't keep track of all of them, which can lead to burdens also, i.e. > if you translate one string which is already contained in another po with a > different plural form, that may be used instead of yours. > > This is against - I believe, not sure, please someone correct me - the > design of gettext on which Django builds upon. Although all .pos have a > header with a plural formula, it is assumed that they will be the same for > a language, so when merging, only the first one is retained. > > Supporting multiple catalogs in order to support different plural forms is > plausible, it seems to be like an extension to gettext, but it may not fix > your problem entirely, because although you may retain the consistency of > your pos, some translations will break (Django's) because of the broken > formula. > > One thing is the break by a broken formula, another thing is changing > Django's one plural form policy. > > (JIC, for those interested in the subject and want to catch up - besides > reading the ticket - a gettext catalog plural form contains 2 things: the > number of plurals of the language and an equation/formula that decides > which one to use for the case. Django uses one "general" gettext catalog > per language which is the result of merging several ""subcatalogs"", > ""local pos"") > > The broken formulas introduced can be fixed by a fix in the repo, and/or > by changing the syncing scripts with Transifex to do a msgmerge instead. > This won't update the plural forms from Django, they will need to be > manually updated on the repo - someone will have to check the updated > formula and see if it is alright, and it has to be someone knowledgeable > about it (I wouldn't be able to discern if the plural form of Slovakian is > good or not, besides an evidently broken one from what I learnt), so I > think this would rely on the django-i18n committee(?) (I guess this would > be more work for them). > > Another thing is the change of the number of plurals. This will not only > imply a change in the plural formula but a change in the entire catalog, as > new translations will be needed. This seems something not to be changed > unless a mistake was found. If this is changed for convenience, in order to > use gettext (and catalog merging), you should ensure that only your > catalogs are used. You can give convenience by making your translation > utility generate the remaining plurals accordingly so they can be merged > with others that contain all the forms. > > Here is a **shamefull, bad, ugly and dirty** script > <https://gist.github.com/math-a3k/7189c1410ef32a810f57d253947e547b> that > will add the remaining entries to your .po in order to be merged with > others that have the total of plurals. Just download it and run > "update-po-plurals your.po from=2 to=4 > your_new.po" and it will be > converted from two to four (although you will have to adjust manually the > header). This way, it will be "merge-able" in every software that uses > gettext with all the plurals ( > https://code.djangoproject.com/ticket/30439#comment:24). > > The only fix that comes to my mind that will solve this is to give the > ability of taking out the locales out from of the django distribution tree > to django project tree. This is making a "collectlocale" command that will > collect and merge all the .pos distributed in django and put them on > settings.LOCALE_ROOT in the project tree. Once this exists, the Django > translation module will start using this as the base for merging. You can > edit them and VC them in your project. This way no update in the Django > locales will affect your translations. You will have to manually run > "collectlocale" on an upgrade to incorporate the changes. You will also > take full benefit of catalog merging. > > For some reason, the Translation community can't come up with one > definitive version of the number of plurals and a plural equation for each > language (gettext gets them from http://cldr.unicode.org/) and different > parts of the community use different formulas. If there were a consensus > here, these problems wouldn't exist. > > A provisional fix was already provided so you can restore your > functionality by updating your project main po plural form, now you can > update the plurals of your po from 2 to 4 that would provide the same > translations results as before the increase of the plurals. > > Do you have any doubts about how to apply the temporarily fixes? > > If not, let's then focus on solving the problem the right way and > definitively :) > > On Sun, Nov 24, 2019 at 4:54 AM אורי <u...@speedy.net> wrote: > >> 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 >> <https://groups.google.com/d/msgid/django-developers/CABD5YeHDLvNTOvbNezkoN%3DOJU67j6pW%2BjOJLcscy5VdV41wz%3Dw%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/CA%2BFDnhLexoNhpw45XsCp2oiJJsX%2B7indCk_3sy2sF857i%2Bz7Ag%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CA%2BFDnhLexoNhpw45XsCp2oiJJsX%2B7indCk_3sy2sF857i%2Bz7Ag%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/CABD5YeFju5Mf7%2Bcgz0xa8W%3DZHVfE82skQq9N%3DCXx0VXTGcERAw%40mail.gmail.com.
