[Django] #30939: Upgrading Django from 2.1 to 2.2 - strings are not translated
Django
-----------------------------------------+------------------------
Reporter: אורי | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 2.2
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-----------------------------------------+------------------------
I tried to upgrade Django from 2.1 to 2.2 in [https://github.com/speedy-
net/speedy-net Speedy Net], and I found out that strings are not
translated to Hebrew any more. Not all the strings, some of the strings.
Especially strings translated with `ngettext_lazy`.
Tests which fail with strings not translated - [https://travis-ci.org
/speedy-net/speedy-net/jobs/605597350 here].
In the Hebrew website I get error messages in English instead of Hebrew.
For example "This password is too long. It must contain at most 120
characters." instead of "סיסמה זו ארוכה מדי. היא יכולה להכיל 120 תווים לכל
היותר." (and other error messages, for example in the registration form).
--
Ticket URL: <https://code.djangoproject.com/ticket/30939>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Reporter: אורי | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 2.2
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by אורי):
I'm not sure, but it might be related to this
[https://github.com/django/django/commit/ae180fa4b7f927a4aeae772975927c9888bb0cb0
commit].
--
Ticket URL: <https://code.djangoproject.com/ticket/30939#comment:1>
Django
Reporter: אורי | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 2.2
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Description changed by אורי:
Old description:
> I tried to upgrade Django from 2.1 to 2.2 in [https://github.com/speedy-
> net/speedy-net Speedy Net], and I found out that strings are not
> translated to Hebrew any more. Not all the strings, some of the strings.
> Especially strings translated with `ngettext_lazy`.
>
> Tests which fail with strings not translated - [https://travis-ci.org
> /speedy-net/speedy-net/jobs/605597350 here].
>
> In the Hebrew website I get error messages in English instead of Hebrew.
> For example "This password is too long. It must contain at most 120
> characters." instead of "סיסמה זו ארוכה מדי. היא יכולה להכיל 120 תווים
> לכל היותר." (and other error messages, for example in the registration
> form).
New description:
I tried to upgrade Django from 2.1 to 2.2 in [https://github.com/speedy-
net/speedy-net Speedy Net], and I found out that strings are not
translated to Hebrew any more. Not all the strings, some of the strings.
Especially strings translated with `ngettext_lazy`.
Tests which fail with strings not translated - [https://travis-ci.org
/speedy-net/speedy-net/jobs/605597350 here].
In the Hebrew website I get error messages in English instead of Hebrew.
For example "This password is too long. It must contain at most 120
characters." instead of "סיסמה זו ארוכה מדי. היא יכולה להכיל 120 תווים לכל
היותר." (and other error messages, for example in the registration form).
Not all the strings translated with `ngettext_lazy` are not translated,
but only some of them. For example, the error message "This password is
too short. It must contain at least 8 characters." is translated to Hebrew
in the Hebrew website and tests.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/30939#comment:2>
Django
Reporter: אורי | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 2.2
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by אורי):
It's a regression, we need to bisect. Everything works in Django versions
up to 2.1.13.
--
Ticket URL: <https://code.djangoproject.com/ticket/30939#comment:3>
Django
Reporter: אורי | Owner: nobody
Type: Uncategorized | Status: new
Component: Uncategorized | Version: 2.2
Keywords: | Triage Stage: Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by אורי):
$ git bisect run ../speedy-net/speedy/net/tests_manage.py test
speedy.core.accounts.tests.test_models.UserHebrewTestCase
98f526e67c2899b9d44ba7cdbab5d70b1baa0060 is the first bad commit
commit 98f526e67c2899b9d44ba7cdbab5d70b1baa0060
Author: Claude Paroz <cla...@2xlibre.net>
Date: Sat Mar 30 11:38:12 2019 +0100
[2.2.x] Updated core translations from Transifex
:040000 040000 d4b445730ca9670d5a9521e1b9140a365ec35ea1
35eeac3fa09f541c819f21d3dfa3b0d985081fed M django
bisect run success
--
Ticket URL: <https://code.djangoproject.com/ticket/30939#comment:4>
Django
Reporter: אורי | Owner: nobody
Type: Uncategorized | Status: closed
Component: | Version: 2.2
Internationalization |
Severity: Normal | Resolution: duplicate
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Claude Paroz):
* status: new => closed
* component: Uncategorized => Internationalization
* resolution: => duplicate
Comment:
I guess this is due to the fact Transifex uses now a different Plural
equation for Hebrew.
Used to be the simple `Plural-Forms: nplurals=2; plural=(n != 1);`, now it
is:
`Plural-Forms: nplurals=4; plural=(n == 1 && n % 1 == 0) ? 0 : (n == 2 &&
n % 1 == 0) ? 1: (n % 10 == 0 && n % 1 == 0 && n > 10) ? 2 : 3;"`
I'm sorry for that change, but we unfortunately have no way AFAIK to
change that ourselves on Transifex.
As Django is currently using the core translations plural equations for
all catalogs, you have to ensure that all catalogs are using 4 plural
variants (which I recognize might be not easy to do for third-party
packages).
Duplicate of #30439, which have discussions on possible fixes in Django.
--
Ticket URL: <https://code.djangoproject.com/ticket/30939#comment:5>
Django
Reporter: אורי | Owner: nobody
Type: Uncategorized | Status: closed
Component: | Version: 2.2
Internationalization |
Severity: Normal | Resolution: duplicate
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by אורי):
I commented on the other ticket as well. 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?
--
Ticket URL: <https://code.djangoproject.com/ticket/30939#comment:6>
Django
Reporter: אורי | Owner: nobody
Type: Uncategorized | Status: closed
Component: | Version: 2.2
Internationalization |
Severity: Normal | Resolution: duplicate
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Claude Paroz):
To be clear, *I* did not decide anything. We are using the Transifex
translation platform which currently imposes Plural strings to hosted
projects. I don't know why they changed that, maybe you should try to talk
to them?
--
Ticket URL: <https://code.djangoproject.com/ticket/30939#comment:7>
Django
Reporter: אורי | Owner: nobody
Type: Uncategorized | Status: closed
Component: | Version: 2.2
Internationalization |
Severity: Normal | Resolution: duplicate
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by אורי):
Replying to [comment:7 Claude Paroz]:
> To be clear, *I* did not decide anything. We are using the Transifex
translation platform which currently imposes Plural strings to hosted
projects. I don't know why they changed that, maybe you should try to talk
to them?
Is it possible to revert the same code that worked in all Django versions
up to 2.1? I think it you (the Django developers) revert the code, it can
solve this problem.
--
Ticket URL: <https://code.djangoproject.com/ticket/30939#comment:8>
Django
Reporter: אורי | Owner: nobody
Type: Uncategorized | Status: closed
Component: | Version: 2.2
Internationalization |
Severity: Normal | Resolution: duplicate
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by Claude Paroz):
Do you understand the implications of what you ask? Do you suggest we stop
updating translations?
--
Ticket URL: <https://code.djangoproject.com/ticket/30939#comment:9>
Django
Reporter: אורי | Owner: nobody
Type: Uncategorized | Status: closed
Component: | Version: 2.2
Internationalization |
Severity: Normal | Resolution: duplicate
| Unreviewed
Has patch: 0 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by אורי):
* needs_docs: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/30939#comment:10>
Django
Reporter: אורי | Owner: nobody
Type: Uncategorized | Status: closed
Component: | Version: 2.2
Internationalization |
Severity: Normal | Resolution: duplicate
| Unreviewed
Has patch: 0 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by אורי):
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/30939#comment:11>
Django
Reporter: אורי | Owner: nobody
Type: Uncategorized | Status: closed
Component: | Version: 2.2
Internationalization |
Severity: Normal | Resolution: duplicate
| Unreviewed
Has patch: 0 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Comment (by אורי):
I checked and I didn't find anything related to this issue documented on
the Django 2.2 release notes. Is it documented?
I created ticket https://code.djangoproject.com/ticket/30945
--
Ticket URL: <https://code.djangoproject.com/ticket/30939#comment:12>
Django
Reporter: אורי | Owner: nobody
Type: Bug | Status: closed
Component: | Version: 2.2
Internationalization |
Severity: Normal | Resolution: duplicate
| Unreviewed
Has patch: 0 | Needs documentation: 1
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by אורי):
* type: Uncategorized => Bug
--
Ticket URL: <https://code.djangoproject.com/ticket/30939#comment:13>