ngettext_lazy and ngettext

Next Topic
 
classic Classic list List threaded Threaded
40 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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"):

And the relevant Django code:

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeG8A%2BfLNom1BrOogYKpfOpfrCxK32OT%3D1dMO-cPyaL9sw%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

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.

‪On Fri, Nov 1, 2019 at 10:18 AM ‫אורי‬‎ <[hidden email]> 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"):

And the relevant Django code:

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeGzsMT3D0JHcH-bEaS0YZm2kY%3DVHTRngDUq3Q%3D640jgLg%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: ngettext_lazy and ngettext

Claude Paroz
In reply to this post by אורי
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

<a href="javascript:" target="_blank" gdf-obfuscated-mailto="j1hRijU4EQAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/9d8ade17-3d6e-46dc-8ad7-a6b27de90593%40googlegroups.com.
Reply | Threaded
Open this post in threaded view
|

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,

On Fri, Nov 1, 2019 at 9:29 PM Claude Paroz <[hidden email]> 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

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/9d8ade17-3d6e-46dc-8ad7-a6b27de90593%40googlegroups.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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeFVwrSUz0VoAZ6wvET%2BJDM%2BkF%2B%3DypPYpfjagHnOrhwx%3Dw%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: ngettext_lazy and ngettext

אורי
In reply to this post by Claude Paroz
Hi,

I checked and I didn't find anything related to this issue documented on the Django 2.2 release notes. Is it documented?

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeE6M89GTd-Tcn09NK3xBrqCmz5zJC040q-FE5TKT8W1dg%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: ngettext_lazy and ngettext

אורי
In reply to this post by אורי
Django developers,


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.

‪On Fri, Nov 1, 2019 at 10:47 AM ‫אורי‬‎ <[hidden email]> 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.

‪On Fri, Nov 1, 2019 at 10:18 AM ‫אורי‬‎ <[hidden email]> 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"):

And the relevant Django code:

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeHjk183hY5bKJk1w8LoVcUXisc5G29c49VzK4y8eUy5JQ%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: ngettext_lazy and ngettext

Adam Johnson-2
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, ‫אורי‬‎ <[hidden email]> wrote:‬
Django developers,


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.

‪On Fri, Nov 1, 2019 at 10:47 AM ‫אורי‬‎ <[hidden email]> 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.

‪On Fri, Nov 1, 2019 at 10:18 AM ‫אורי‬‎ <[hidden email]> 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"):

And the relevant Django code:

--
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 [hidden email].
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 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM229eLs6cHZkE3oFh5Sd8cLAsMyiwQCRTKqMT9U%3D4kkHQ%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

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?


On Sat, Nov 23, 2019 at 2:29 PM Adam Johnson <[hidden email]> 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, ‫אורי‬‎ <[hidden email]> wrote:‬
Django developers,


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.

‪On Fri, Nov 1, 2019 at 10:47 AM ‫אורי‬‎ <[hidden email]> 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.

‪On Fri, Nov 1, 2019 at 10:18 AM ‫אורי‬‎ <[hidden email]> 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"):

And the relevant Django code:

--
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 [hidden email].
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 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM229eLs6cHZkE3oFh5Sd8cLAsMyiwQCRTKqMT9U%3D4kkHQ%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 to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeHNEC3hRmnfhABm3gRRPUCgfqQkOeOXoBEFFTbg_v4Fcw%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: ngettext_lazy and ngettext

אורי
In reply to this post by Adam Johnson-2
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.

On Sat, Nov 23, 2019 at 2:29 PM Adam Johnson <[hidden email]> 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, ‫אורי‬‎ <[hidden email]> wrote:‬
Django developers,


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.

‪On Fri, Nov 1, 2019 at 10:47 AM ‫אורי‬‎ <[hidden email]> 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.

‪On Fri, Nov 1, 2019 at 10:18 AM ‫אורי‬‎ <[hidden email]> 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"):

And the relevant Django code:

--
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 [hidden email].
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 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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM229eLs6cHZkE3oFh5Sd8cLAsMyiwQCRTKqMT9U%3D4kkHQ%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 to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeGagCyqsfOb2%3DhQDrmSL-xJstPQeRY6Uuiig%2BfY-EYbEQ%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: ngettext_lazy and ngettext

Tobias McNulty
In reply to this post by אורי
‪On Sat, Nov 23, 2019 at 9:17 AM ‫אורי‬‎ <[hidden email]> 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

[hidden email]
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMGFDKTM_uhYYC7R7oaADfK%3D_4kaMNjH5U8FQ1q%3DYVdutzpwEg%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: ngettext_lazy and ngettext

אורי
Hi,

Please see my latest comment on this ticket:

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.


On Sun, Nov 24, 2019 at 2:50 AM Tobias McNulty <[hidden email]> wrote:
‪On Sat, Nov 23, 2019 at 9:17 AM ‫אורי‬‎ <[hidden email]> 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

[hidden email]
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 [hidden email].
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 to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeHu%3Dvf9HJZHDdSVFAf0V1XoEh-YX32SsR5ndq3v-SJ9zg%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

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.


‪On Sun, Nov 24, 2019 at 4:31 AM ‫אורי‬‎ <[hidden email]> wrote:‬
Hi,

Please see my latest comment on this ticket:

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.


On Sun, Nov 24, 2019 at 2:50 AM Tobias McNulty <[hidden email]> wrote:
‪On Sat, Nov 23, 2019 at 9:17 AM ‫אורי‬‎ <[hidden email]> 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

[hidden email]
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 [hidden email].
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 to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeFrEqL-ksknPfyKggASH1WKwNX1i3AeKxVOzP38TuPS_w%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

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 אורי <[hidden email]> 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.


‪On Sun, Nov 24, 2019 at 4:31 AM ‫אורי‬‎ <[hidden email]> wrote:‬
Hi,

Please see my latest comment on this ticket:

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.


On Sun, Nov 24, 2019 at 2:50 AM Tobias McNulty <[hidden email]> wrote:
‪On Sat, Nov 23, 2019 at 9:17 AM ‫אורי‬‎ <[hidden email]> 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

[hidden email]
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 [hidden email].
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 to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeFrEqL-ksknPfyKggASH1WKwNX1i3AeKxVOzP38TuPS_w%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 to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMGFDKTdj4KL_P3kaft1e5hwA%3DYWGDs%3DojWNUJKb05GBw%3D2M5g%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

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

On Sun, Nov 24, 2019 at 6:37 AM Tobias McNulty <[hidden email]> 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 אורי <[hidden email]> 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.


‪On Sun, Nov 24, 2019 at 4:31 AM ‫אורי‬‎ <[hidden email]> wrote:‬
Hi,

Please see my latest comment on this ticket:

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.


On Sun, Nov 24, 2019 at 2:50 AM Tobias McNulty <[hidden email]> wrote:
‪On Sat, Nov 23, 2019 at 9:17 AM ‫אורי‬‎ <[hidden email]> 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

[hidden email]
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 [hidden email].
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 to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeFrEqL-ksknPfyKggASH1WKwNX1i3AeKxVOzP38TuPS_w%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 to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMGFDKTdj4KL_P3kaft1e5hwA%3DYWGDs%3DojWNUJKb05GBw%3D2M5g%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 to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeHDLvNTOvbNezkoN%3DOJU67j6pW%2BjOJLcscy5VdV41wz%3Dw%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: ngettext_lazy and ngettext

Matemática A3K

,אורי

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 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 ‫אורי‬‎ <[hidden email]> 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].

On Sun, Nov 24, 2019 at 6:37 AM Tobias McNulty <[hidden email]> 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 אורי <[hidden email]> 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.


‪On Sun, Nov 24, 2019 at 4:31 AM ‫אורי‬‎ <[hidden email]> wrote:‬
Hi,

Please see my latest comment on this ticket:

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.


On Sun, Nov 24, 2019 at 2:50 AM Tobias McNulty <[hidden email]> wrote:
‪On Sat, Nov 23, 2019 at 9:17 AM ‫אורי‬‎ <[hidden email]> 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

[hidden email]
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 [hidden email].
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 to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeFrEqL-ksknPfyKggASH1WKwNX1i3AeKxVOzP38TuPS_w%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 to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMGFDKTdj4KL_P3kaft1e5hwA%3DYWGDs%3DojWNUJKb05GBw%3D2M5g%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 to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeHDLvNTOvbNezkoN%3DOJU67j6pW%2BjOJLcscy5VdV41wz%3Dw%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 to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CA%2BFDnhLexoNhpw45XsCp2oiJJsX%2B7indCk_3sy2sF857i%2Bz7Ag%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: ngettext_lazy and ngettext

אורי
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.

On Mon, Nov 25, 2019 at 1:40 AM Matemática A3K <[hidden email]> 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 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 ‫אורי‬‎ <[hidden email]> 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].

On Sun, Nov 24, 2019 at 6:37 AM Tobias McNulty <[hidden email]> 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 אורי <[hidden email]> 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.


‪On Sun, Nov 24, 2019 at 4:31 AM ‫אורי‬‎ <[hidden email]> wrote:‬
Hi,

Please see my latest comment on this ticket:

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.


On Sun, Nov 24, 2019 at 2:50 AM Tobias McNulty <[hidden email]> wrote:
‪On Sat, Nov 23, 2019 at 9:17 AM ‫אורי‬‎ <[hidden email]> 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

[hidden email]
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 [hidden email].
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 to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeFrEqL-ksknPfyKggASH1WKwNX1i3AeKxVOzP38TuPS_w%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 to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMGFDKTdj4KL_P3kaft1e5hwA%3DYWGDs%3DojWNUJKb05GBw%3D2M5g%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 to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeHDLvNTOvbNezkoN%3DOJU67j6pW%2BjOJLcscy5VdV41wz%3Dw%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 to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CA%2BFDnhLexoNhpw45XsCp2oiJJsX%2B7indCk_3sy2sF857i%2Bz7Ag%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 to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeFju5Mf7%2Bcgz0xa8W%3DZHVfE82skQq9N%3DCXx0VXTGcERAw%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: ngettext_lazy and ngettext

Matemática A3K


‪On Mon, Nov 25, 2019 at 6:26 AM ‫אורי‬‎ <[hidden email]> wrote:‬
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.

אורי,

OK, have in mind that a change of the number of plurals for a language is kind (if not) of an API change for i18n - now you have to feed a different input - and should be handled as such. There is no way of modifying your code on an upgrade by the software distribution (the package).

Did the script that I posted not do the job?

 

On Mon, Nov 25, 2019 at 1:40 AM Matemática A3K <[hidden email]> 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 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 ‫אורי‬‎ <[hidden email]> 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].

On Sun, Nov 24, 2019 at 6:37 AM Tobias McNulty <[hidden email]> 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 אורי <[hidden email]> 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.


‪On Sun, Nov 24, 2019 at 4:31 AM ‫אורי‬‎ <[hidden email]> wrote:‬
Hi,

Please see my latest comment on this ticket:

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.


On Sun, Nov 24, 2019 at 2:50 AM Tobias McNulty <[hidden email]> wrote:
‪On Sat, Nov 23, 2019 at 9:17 AM ‫אורי‬‎ <[hidden email]> 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

[hidden email]
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 [hidden email].
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 to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeFrEqL-ksknPfyKggASH1WKwNX1i3AeKxVOzP38TuPS_w%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 to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMGFDKTdj4KL_P3kaft1e5hwA%3DYWGDs%3DojWNUJKb05GBw%3D2M5g%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 to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeHDLvNTOvbNezkoN%3DOJU67j6pW%2BjOJLcscy5VdV41wz%3Dw%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 to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CA%2BFDnhLexoNhpw45XsCp2oiJJsX%2B7indCk_3sy2sF857i%2Bz7Ag%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 to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeFju5Mf7%2Bcgz0xa8W%3DZHVfE82skQq9N%3DCXx0VXTGcERAw%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 to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CA%2BFDnh%2B3TBT7PBN3E7Z3axtmdR87g0hDbnHDQmYkq93qhwXxLQ%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: ngettext_lazy and ngettext

אורי


On Tue, Nov 26, 2019 at 8:13 AM Matemática A3K <[hidden email]> wrote:


‪On Mon, Nov 25, 2019 at 6:26 AM ‫אורי‬‎ <[hidden email]> wrote:‬

אורי,

OK, have in mind that a change of the number of plurals for a language is kind (if not) of an API change for i18n - now you have to feed a different input - and should be handled as such. There is no way of modifying your code on an upgrade by the software distribution (the package).

Did the script that I posted not do the job?
 
No offense, but I didn't try. As a Django user I don't expect Django to send me to install and run third party scripts that will keep my sites working when I upgrade Django. I also don't think there is need for 4 plural forms in my .po files. I would like to keep using 2 plural forms as that makes more sense to me.

I decided to keep using Django 2.1.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeH%3DwqNcWsu5_Lzab39qmcDPY%2BymGD2k-R1mbr%3DEiCvbnQ%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: ngettext_lazy and ngettext

Maciek Olko
It looks like Transifex uses [1] Unicode Language Plural Rules [2]. If they are incorrect for Hebrew, maybe they should be fixed on Unicode side?

Regards,
Maciej


‪wt., 26 lis 2019 o 08:18 ‫אורי‬‎ <[hidden email]> napisał(a):‬


On Tue, Nov 26, 2019 at 8:13 AM Matemática A3K <[hidden email]> wrote:


‪On Mon, Nov 25, 2019 at 6:26 AM ‫אורי‬‎ <[hidden email]> wrote:‬

אורי,

OK, have in mind that a change of the number of plurals for a language is kind (if not) of an API change for i18n - now you have to feed a different input - and should be handled as such. There is no way of modifying your code on an upgrade by the software distribution (the package).

Did the script that I posted not do the job?
 
No offense, but I didn't try. As a Django user I don't expect Django to send me to install and run third party scripts that will keep my sites working when I upgrade Django. I also don't think there is need for 4 plural forms in my .po files. I would like to keep using 2 plural forms as that makes more sense to me.

I decided to keep using Django 2.1.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeH%3DwqNcWsu5_Lzab39qmcDPY%2BymGD2k-R1mbr%3DEiCvbnQ%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 to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CALYYG818kvK%3DPRxj1C_DS-xB5tKkS2zFiBUL02AT5xyWvUNHLw%40mail.gmail.com.
Reply | Threaded
Open this post in threaded view
|

Re: ngettext_lazy and ngettext

אורי
Hi Maciej,

I would not say the rules are incorrect. It depends on the case. In some cases they might be correct and there might be 3, 4 or even more plural forms. But in many other cases, two plural forms are enough. It depends on the strings being translated. I think in most cases, two plural forms are correct, like was in Django up to 2.1.

For example in weeks, there is a word in hebrew for "two weeks" ("שבועיים"), which is more correct than writing two words for two weeks ("2 שבועות"). But in other cases, there is not a specific word for "2 <objects>". In the case of Speedy Net for example, I used function ngettext_lazy in a validator validating the number of characters in a password or username. In these cases, only the plain plural form should be used, and anyway the number given there is probable not 1 and also not 2. It might be in some specific cases 6, 8 or 120, and there is no specific plural form for that number of characters. The translation is just using the Hebrew word for characters ("תווים"). Even if this number was 2, it would have used the same word, but there is a singular word for 1.

On Tue, Nov 26, 2019 at 1:29 PM Maciek Olko <[hidden email]> wrote:
It looks like Transifex uses [1] Unicode Language Plural Rules [2]. If they are incorrect for Hebrew, maybe they should be fixed on Unicode side?

Regards,
Maciej


‪wt., 26 lis 2019 o 08:18 ‫אורי‬‎ <[hidden email]> napisał(a):‬


On Tue, Nov 26, 2019 at 8:13 AM Matemática A3K <[hidden email]> wrote:


‪On Mon, Nov 25, 2019 at 6:26 AM ‫אורי‬‎ <[hidden email]> wrote:‬

אורי,

OK, have in mind that a change of the number of plurals for a language is kind (if not) of an API change for i18n - now you have to feed a different input - and should be handled as such. There is no way of modifying your code on an upgrade by the software distribution (the package).

Did the script that I posted not do the job?
 
No offense, but I didn't try. As a Django user I don't expect Django to send me to install and run third party scripts that will keep my sites working when I upgrade Django. I also don't think there is need for 4 plural forms in my .po files. I would like to keep using 2 plural forms as that makes more sense to me.

I decided to keep using Django 2.1.

--
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 [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeH%3DwqNcWsu5_Lzab39qmcDPY%2BymGD2k-R1mbr%3DEiCvbnQ%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 to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CALYYG818kvK%3DPRxj1C_DS-xB5tKkS2zFiBUL02AT5xyWvUNHLw%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 to [hidden email].
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeHFx0aTeKOuKyc5To%2BvR%2B61nO6kVbs7HbP4yR8JZqOsbQ%40mail.gmail.com.
12