Re: ngettext_lazy and ngettext

[אורי]

Django developers,

https://code.djangoproject.com/ticket/30439

I think Django 2.2 (which is LTS) should be updated in a way that using
these functions to translate will be backward-compatible, so that
everything that worked with Django up to 2.1 will keep working in Django
2.2 and above. Currently this is not the case in Hebrew with Speedy Net
, which starts displaying error
messages in English in the Hebrew websites (Speedy Net & Speedy Match) when
I upgrade Django to 2.2, which is *not* what I expect. In Django up to 2.1
these error messages are translated to Hebrew, which *is* what I expect.

After encountering this problem I decided to keep Speedy Net in Django 2.1
(which I upgraded from 1.11 about 3 weeks ago) until there is a solution,
or at least until I can make Speedy Net work in Hebrew in Django 2.2 and
above. However, I understand the end-of-life of Django 2.1 is coming soon,
which means we will be using an obsolete version of Django in a production
website.

As long as this issue is not resolved, I would appreciate if you will
extend the end-of-life date of Django 2.1 to at least one or two months
after this issue will be resolved. Yes I know I can downgrade Django to
1.11 and use it until April 2020, but since I already upgraded to 2.1 I'm
not sure it's a good idea to downgrade Django now. And also, since Django
2.2 was released almost 8 months ago, I'm not sure if this problem will be
resolved before April 2020. #30439
 was opened about 7 months ago
and it's still not resolved.

אורי
u...@speedy.net


‪On Fri, Nov 1, 2019 at 10:47 AM ‫אורי‬‎  wrote:‬

> 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/CABD5YeHjk183hY5bKJk1w8LoVcUXisc5G29c49VzK4y8eUy5JQ%40mail.gmail.com.

Re: ngettext_lazy and ngettext

[Adam Johnson]

Uri,

I understand this is frustrating for you as a user. Thank you for
documenting your issues extensively so they're easy to follow. However it
seems like a complicated problem and that Claude is the only person
spending significant time working on translations these days. If you have
some resources to try help fix the bug, or document the workaround (running
makemessages after upgrade?) that would be helpful to the community.

Thanks,

Adam

‪On Sat, 23 Nov 2019 at 11:32, ‫אורי‬‎  wrote:‬

> Django developers,
>
> https://code.djangoproject.com/ticket/30439
>
> I think Django 2.2 (which is LTS) should be updated in a way that using
> these functions to translate will be backward-compatible, so that
> everything that worked with Django up to 2.1 will keep working in Django
> 2.2 and above. Currently this is not the case in Hebrew with Speedy Net
> , which starts displaying error
> messages in English in the Hebrew websites (Speedy Net & Speedy Match) when
> I upgrade Django to 2.2, which is *not* what I expect. In Django up to
> 2.1 these error messages are translated to Hebrew, which *is* what I
> expect.
>
> After encountering this problem I decided to keep Speedy Net in Django 2.1
> (which I upgraded from 1.11 about 3 weeks ago) until there is a solution,
> or at least until I can make Speedy Net work in Hebrew in Django 2.2 and
> above. However, I understand the end-of-life of Django 2.1 is coming soon,
> which means we will be using an obsolete version of Django in a production
> website.
>
> As long as this issue is not resolved, I would appreciate if you will
> extend the end-of-life date of Django 2.1 to at least one or two months
> after this issue will be resolved. Yes I know I can downgrade Django to
> 1.11 and use it until April 2020, but since I already upgraded to 2.1 I'm
> not sure it's a good idea to downgrade Django now. And also, since Django
> 2.2 was released almost 8 months ago, I'm not sure if this problem will be
> resolved before April 2020. #30439
>  was opened about 7 months
> ago and it's still not resolved.
>
> אורי
> u...@speedy.net
>
>
> ‪On Fri, Nov 1, 2019 at 10:47 AM ‫אורי‬‎  wrote:‬
>
>> 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/CABD5YeHjk183hY5bKJk1w8LoVcUXisc5G29c49VzK4y8eUy5JQ%40mail.gmail.com
> 
> .
>


-- 
Adam

-- 
You received this message because you a

Re: ngettext_lazy and ngettext

[אורי]

Hi Adam / Django developers,

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
 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? After documenting this problem, I
can see if I can submit a change to the code itself. However I'm not sure
if you will accept it, since what I want is mainly to maintain the
functionality of these functions in Django up to 2.1, which means I'm not
sure how new changes will work in Django 2.2. *But*, I think what we have
right now is not an acceptable solution, because functionality of these two
functions breaks when upgrading Django to 2.2, which means that these
functions stop working in some cases (such as in Speedy Net & Hebrew) when
upgrading Django to 2.2 - the output is like we didn't call the translating
functions at all (the functions return the same string in English, not
translated).

By the way, you said it's a complicated problem. I'm not sure about other
languages, but at least in Hebrew, as far as I know, it was very simple in
Django up to 2.1. Either n==1, or n!=1 - there were two strings and
everything worked. I don't think it should be that complicated and actually
I suggested that if you (the Django developers) want a more complicated
functionality you should introduce new functions and not change the
(working) functionality of existing functions, or at least change them in a
backward-compatible way. And as far as I know, ngettext_lazy and ngettext
worked without problems until Django 2.1 (at least in Hebrew, I'm not sure
about other languages).

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?

אורי
u...@speedy.net


On Sat, Nov 23, 2019 at 2:29 PM Adam Johnson  wrote:

> Uri,
>
> I understand this is frustrating for you as a user. Thank you for
> documenting your issues extensively so they're easy to follow. However it
> seems like a complicated problem and that Claude is the only person
> spending significant time working on translations these days. If you have
> some resources to try help fix the bug, or document the workaround (running
> makemessages after upgrade?) that would be helpful to the community.
>
> Thanks,
>
> Adam
>
> ‪On Sat, 23 Nov 2019 at 11:32, ‫אורי‬‎  wrote:‬
>
>> Django developers,
>>
>> https://code.djangoproject.com/ticket/30439
>>
>> I think Django 2.2 (which is LTS) should be updated in a way that using
>> these functions to translate will be backward-compatible, so that
>> everything that worked with Django up to 2.1 will keep working in Django
>> 2.2 and above. Currently this is not the case in Hebrew with Speedy Net
>> , which starts displaying
>> error messages in English in the Hebrew websites (Speedy Net & Speedy
>> Match) when I upgrade Django to 2.2, which is *not* what I expect. In
>> Django up to 2.1 these error messages are translated to Hebrew, which
>> *is* what I expect.
>>
>> After encountering this problem I decided to keep Speedy Net in Django
>> 2.1 (which I upgraded from 1.11 about 3 weeks ago) until there is a
>> solution, or at least until I can make Speedy Net work in Hebrew in Django
>> 2.2 and above. However, I understand the end-of-life of Django 2.1 is
>> coming soon, which means we will be using an obsolete version of Django in
>> a production website.
>>
>> As long as this issue is not resolved, I would appreciate if you will
>> extend the end-of-life date of Django 2.1 to at least one or two months
>> after this issue will be resolved. Yes I know I can downgrade Django to
>> 1.11 and use it until April 2020, but since I already upgraded to 2.1 I'm
>> not sure it's a good idea to downgrade Django now. And also, since Django
>> 2.2 was released almost 8 months ago, I'm not sure if this problem will be
>> resolved before April 2020. #30439
>>  was opened about 7 months
>> ago and it's still not resolved.
>>
>> אורי
>> u...@speedy.net
>>
>>
>> ‪On Fri, Nov 1, 2019 at 10:47 AM ‫אורי‬‎  wrote:‬
>>
>>> 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 v

Re: ngettext_lazy and ngettext

[אורי]

Hi Adam / Django developers,

I want to clarify if it was not clear - running makemessages after
upgrading Django to 2.2 doesn't solve this problem. It doesn't. At least
not in Hebrew. I didn't see any changes in the Django .po files after
running makemessages in Django 2.2.

אורי
u...@speedy.net


On Sat, Nov 23, 2019 at 2:29 PM Adam Johnson  wrote:

> Uri,
>
> I understand this is frustrating for you as a user. Thank you for
> documenting your issues extensively so they're easy to follow. However it
> seems like a complicated problem and that Claude is the only person
> spending significant time working on translations these days. If you have
> some resources to try help fix the bug, or document the workaround (running
> makemessages after upgrade?) that would be helpful to the community.
>
> Thanks,
>
> Adam
>
> ‪On Sat, 23 Nov 2019 at 11:32, ‫אורי‬‎  wrote:‬
>
>> Django developers,
>>
>> https://code.djangoproject.com/ticket/30439
>>
>> I think Django 2.2 (which is LTS) should be updated in a way that using
>> these functions to translate will be backward-compatible, so that
>> everything that worked with Django up to 2.1 will keep working in Django
>> 2.2 and above. Currently this is not the case in Hebrew with Speedy Net
>> , which starts displaying
>> error messages in English in the Hebrew websites (Speedy Net & Speedy
>> Match) when I upgrade Django to 2.2, which is *not* what I expect. In
>> Django up to 2.1 these error messages are translated to Hebrew, which
>> *is* what I expect.
>>
>> After encountering this problem I decided to keep Speedy Net in Django
>> 2.1 (which I upgraded from 1.11 about 3 weeks ago) until there is a
>> solution, or at least until I can make Speedy Net work in Hebrew in Django
>> 2.2 and above. However, I understand the end-of-life of Django 2.1 is
>> coming soon, which means we will be using an obsolete version of Django in
>> a production website.
>>
>> As long as this issue is not resolved, I would appreciate if you will
>> extend the end-of-life date of Django 2.1 to at least one or two months
>> after this issue will be resolved. Yes I know I can downgrade Django to
>> 1.11 and use it until April 2020, but since I already upgraded to 2.1 I'm
>> not sure it's a good idea to downgrade Django now. And also, since Django
>> 2.2 was released almost 8 months ago, I'm not sure if this problem will be
>> resolved before April 2020. #30439
>>  was opened about 7 months
>> ago and it's still not resolved.
>>
>> אורי
>> u...@speedy.net
>>
>>
>> ‪On Fri, Nov 1, 2019 at 10:47 AM ‫אורי‬‎  wrote:‬
>>
>>> 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 

Re: ngettext_lazy and ngettext

[Tobias McNulty]

‪On Sat, Nov 23, 2019 at 9:17 AM ‫אורי‬‎  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.

Re: ngettext_lazy and ngettext

[אורי]

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 
wrote:

> ‪On Sat, Nov 23, 2019 at 9:17 AM ‫אורי‬‎  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
> 
> .
>

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

Re: ngettext_lazy and ngettext

[אורי]

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 ‫אורי‬‎  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 
> wrote:
>
>> ‪On Sat, Nov 23, 2019 at 9:17 AM ‫אורי‬‎  wrote:‬
>>
>>> By the way, I read here that this bug it the fault of Transifex (not
>>> Django). I'm not

Re: ngettext_lazy and ngettext

[Tobias McNulty]

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 אורי  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 ‫אורי‬‎  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 ch

Re: ngettext_lazy and ngettext

[אורי]

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 
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 אורי  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 ‫אורי‬‎  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 i