--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/9d8ade17-3d6e-46dc-8ad7-a6b27de90593%40googlegroups.com.
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 אורי <u...@speedy.net> 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 אורי <u...@speedy.net> 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 django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeHjk183hY5bKJk1w8LoVcUXisc5G29c49VzK4y8eUy5JQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM229eLs6cHZkE3oFh5Sd8cLAsMyiwQCRTKqMT9U%3D4kkHQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM229eLs6cHZkE3oFh5Sd8cLAsMyiwQCRTKqMT9U%3D4kkHQ%40mail.gmail.com.
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?
Tobias McNulty
Chief Executive Officer
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMGFDKTM_uhYYC7R7oaADfK%3D_4kaMNjH5U8FQ1q%3DYVdutzpwEg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeFrEqL-ksknPfyKggASH1WKwNX1i3AeKxVOzP38TuPS_w%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMGFDKTdj4KL_P3kaft1e5hwA%3DYWGDs%3DojWNUJKb05GBw%3D2M5g%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeHDLvNTOvbNezkoN%3DOJU67j6pW%2BjOJLcscy5VdV41wz%3Dw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CA%2BFDnhLexoNhpw45XsCp2oiJJsX%2B7indCk_3sy2sF857i%2Bz7Ag%40mail.gmail.com.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeFju5Mf7%2Bcgz0xa8W%3DZHVfE82skQq9N%3DCXx0VXTGcERAw%40mail.gmail.com.
On Mon, Nov 25, 2019 at 6:26 AM אורי <u...@speedy.net> 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?
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CALYYG818kvK%3DPRxj1C_DS-xB5tKkS2zFiBUL02AT5xyWvUNHLw%40mail.gmail.com.
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?
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeHFx0aTeKOuKyc5To%2BvR%2B61nO6kVbs7HbP4yR8JZqOsbQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CALYYG80jemKnYUmrirWucCor-vJgk-vSoXP8xs2kg81zV27nRw%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 django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20191126195144.066b511b.shai%40platonix.com.
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
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.
Changes in the number of plurals for a language should be included in the Release Notes, as it is changing the i18n API.
On Tue, Nov 26, 2019 at 12:51 PM Shai Berger <sh...@platonix.com> wrote:On Tue, 26 Nov 2019 12:28:45 +0100
Maciek Olko <macie...@gmail.com> 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?
>
Just for the record, they are indeed wrong -- not in the sense that has
sparked this thread (there are indeed 4 forms) but in the rules (the
"many" rule should say "2 < n <= 10", not "n % 10 = 0"). I'm looking
into fixing it.Django's?The problem raised from Django sync'ing with Transifex without any notice of plural rules changes. These changes led sometimes to break Django's translations, other times third-party translations and other times both.For what I have understood, this is a script-driven process. This has to be changed if Django is going to maintain the plural rules "independently", because they will get overwritten in the next sync.Maintaining the plural rules "independently" should be the best way to handle this - IMO - although the project may not have the resources for all the languages it provides translations. This would be sync'ing "only strings", not plural rules (forms and equations).Changes in the number of plurals for a language should be included in the Release Notes, as it is changing the i18n API.Changes in the plural equation doesn't seem necessary to me (to include in the RN) as they would be for the better - given the number of plurals is the same, the new equation should provide an improvement of the results with the same input - - well, mentioning them won't hurt anybody but it isn't necessary :)If Django detects a catalog with a different number of plurals than its main, then it won't be merged and a warning should be shown (something like "Catalog not merged to prevent inconsistencies due to a different number of plurals than the main catalog. See https://docs.djangoproject.com/en/2.2/topics/i18n/translation/#pluralization"). The documentation should contain information on how to increase the number of plurals seamlessly of your catalog to match Django's (the most likely case).If an inconsistency is seen due to a plural equation, it should be reported as a bug. As it is not sync'ed anymore, it can be fixed for Django. The documentation should contain information on how to fix it immediately for your project while the fix is done at the "Django level".This is under the assumptions that:- There is one plural equation which can describe entirely the language's plurals- The policy in https://docs.djangoproject.com/en/2.2/topics/i18n/translation/#pluralization - final note, is correctGiving a convenient complete control of locales persistent to upgrades - a "collectlocales" command - can be left for later or a third-party package.
Do you think this a viable way to solve the issue?
(...)
But, then I realized that there is major caveat on this approach, and that is that updates on the plural equation won't reach users' catalogs, because their catalogs will be kept separately one the plural form differs. This would be the case that Shai pointed on Django 2.2 with the incorrect plural equation for HE. People who have generated their catalogs with makemessages on 2.2 will have a wrong plural equation, that once it is fixed on a new release, it won't reach their catalogs because they will be kept apart.
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 django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5f2bf52a-997c-467d-b927-f2959507d32e%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CA%2BFDnhKtEB4sgUFwmyaExGLSnMU5yLkj0QZ1ubpF2gaRjBd1EQ%40mail.gmail.com.
Hi,I am wondering if Django shouldn't use Unicode Plural Rules as standard and promote it for third-party apps. Even if sometimes number of forms are not applicable to certain cases, there may be cases when all of forms will be needed.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CALYYG80tyJdmEw1LJaV0sa6OHQ0HMkecO2wsHJkvvyQ4%3DT0Tzw%40mail.gmail.com.
On Thu, Dec 5, 2019 at 4:23 PM Maciek Olko <macie...@gmail.com> wrote:Hi,I am wondering if Django shouldn't use Unicode Plural Rules as standard and promote it for third-party apps. Even if sometimes number of forms are not applicable to certain cases, there may be cases when all of forms will be needed.I agree for Django, for third-party translations, for what I understood (CIIW) this may be a differentiatorEspecially if implementing having different plural rules for various apps is not trivial.For the record, here is a section of Transifex documentation that describes their statement about plural rules and Unicode standard: https://docs.transifex.com/localization-tips-workflows/plurals-and-genders#how-pluralized-strings-are-handled-by-transifex .
On Thu, Dec 5, 2019 at 4:23 PM Maciek Olko <macie...@gmail.com> wrote:Hi,I am wondering if Django shouldn't use Unicode Plural Rules as standard and promote it for third-party apps. Even if sometimes number of forms are not applicable to certain cases, there may be cases when all of forms will be needed.I agree for Django, for third-party translations, for what I understood (CIIW) this may be a differentiator
Does anyone see any rationale, design or implementation problem in the fix? Any comment is welcomed :)
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CA%2BFDnhJ7o%3Dhu3cG1gyN85HyjApOEeraD%2BJMG%3DbmG-jb5aj14Cw%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 django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeEjTbzZhSng%3DtN8k-85-qMiRH%2BgqpkG_nOZN9nMxF2YCw%40mail.gmail.com.
Trying to recap all the discussion done in the mailing list, Trac and Github:The problem that was originally reported in #30439 was about mixed plural forms in catalogs bundled with Django, which led to broken translations.Then, it added the not announced changes in the plural forms of locales, which led to break users' translations.These problems occur when catalogs gets updated in Django and users updates their version.Michal proposed not merging and doing catalogs look-ups per language, Claude proposed the "dict-merge" policy (have a dict of merged catalogs according to their plural forms), which is a variant of Michal's.The "dict-merge" policy have the problem of updates in the plural forms in Django won't reach users' catalogs.Whether merge or not merge the catalogs (the merging policy) is about how to encourage the user to take action, not the fix itself.The fix is on the warning of the situation and on the tools for addressing it.The proposed fix is:1- Warn the user at a system check level and at run-time2- Use the "not-merge" policy to encourage action.3- Provide the makemessages --comply-plural-forms tool so both Django and its users can have consistent plural forms in their catalogs conveniently.4- Provide the LOCALE_ROOT setting and the makemessages --collect-base-catalogs tool so users can make changes in their plural forms conveniently and persisted across updates.The PR is cluttered with a lot of inconsistencies fixes across all catalogs bundled with Django and the catalogs used for tests.Once a warning is raised when merging (either merging or not), most of the tests will fail because of that warning, so all bundled catalogs (and those used for tests) have to be aligned in order to have things working.Here are the files of the PR filtered: https://github.com/django/django/pull/12280/files?file-filters%5B%5D=.py&file-filters%5B%5D=.txtFor ensuring Django's catalogs consistency, there is a test that will fail if there is any catalog unaligned. The next time Django's catalogs will be updated, CI will check the consistency. If not, who will do the merge has to run "python -m django makemessages --comply-plural-forms" and "python -m django compilemessages" on the corresponding dir (django.conf, django.contrib.app or the test locale) to fix it. This way, the messages from the provider will be retained and the consistency be assured.There are valid reasons for users to customize their plural forms, i.e. fixing a broken one while a fix is in the way or use another implementation of the standard. Having to modify the source distribution for customizing is not ideal, besides not being persistent across updates and may not be possible in some setups. This should be done locally, at the project tree. This is what the LOCALE_ROOT setting addresses.Claude already objected this fix though he did not provide reasons (https://github.com/django/django/pull/12280#issuecomment-571483273).Does anyone see any rationale, design or implementation problem in the fix? Any comment is welcomed :)
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CA%2BFDnhL_rh4CA_NOZoBcWBJge03HRt0WeTz3bA4iSiZqpY-TyA%40mail.gmail.com.
Django developers,PR #12332 is waiting to be reviewed and approved.I would also like to suggest to include this PR, if accepted, into the next version of 2.2. Otherwise I will not be able to use 2.2 or I will have to fork Django to use 2.2, and then I will have to apply every patch manually to my fork, which is a harass and I don't think should be necessary.
On Tue, Jan 28, 2020 at 7:42 AM Matemática A3K <matema...@gmail.com> wrote:
To unsubscribe from this group and stop receiving emails from it, send an email to django-d...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5f2bf52a-997c-467d-b927-f2959507d32e%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 django-d...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CA%2BFDnhKtEB4sgUFwmyaExGLSnMU5yLkj0QZ1ubpF2gaRjBd1EQ%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 django-d...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CALYYG80tyJdmEw1LJaV0sa6OHQ0HMkecO2wsHJkvvyQ4%3DT0Tzw%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 django-d...@googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeGCfRT07uRpM3phmQFpNJz%2BFouKt1N4Ty%3D9tC0-Uz-Bjw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJwKpyTngRNidxiJXsc7a3McQqtVp-TSjrdWheCq5s6j8r%3DLwg%40mail.gmail.com.
Yes, I understand. Don't merge incorrect solutions. But notice that it is a regression, in the affected languages. Things just stop working after upgrading Django. If I didn't have the unit tests which failed, I might have upgraded Django to production and my users would have received messages in an incorrect language. There is not even an exception raised when the messages are not translated. It just happens that the language I'm using is not the most popular language Django users are using, but it is a regression. It's also not documented in the release notes, as I would expect it to be documented there.אורי
On Wed, Mar 4, 2020 at 7:22 PM Carlton Gibson <carlto...@gmail.com> wrote:
We are taking it seriously Uri. It’s difficult to resolve instantly when there’s a super long mailing list thread, and several PRs in play, and a major discussion on the ticket. It’s only recently that the correct approach has become clear. It’s taken a community effort, from i18n experts to get there.Before that there was pressure to quickly merge incorrect solutions.Then we have security issues to resolve, such as two SQL injection issues in the last couple of months. These take priority.Sorry if things go slower than you’d like. There’s more to it than perhaps there seems. (Not least the danger of introducing regressions, especially if we do decide to backport, as you’d like.)
On Wed, 4 Mar 2020 at 18:14, אורי <u...@speedy.net> wrote:
--Hi Carlton,I think this issue is important for the Django developers mailing list. I already commented on the PR about 3 weeks ago. Yes I know that most Django users use either English, or a language which its plural forms were not changed recently. But users who use a language whose plural forms changed, for example Hebrew in Django 2.2, have problems upgrading Django to 2.2 without serious consequences. I don't know how many users like this there are, except the users who commented on this ticket, which are only about 4 or 5 users as far as I remember. But think about it this way - if the language affected was English, would you act differently? The ticket is from 10 months ago (May 2019), since then there is a problem with Django 2.2, and I noticed you released recently a new Django version. I think you (the Django developers) should take this issue seriously and not like "That one user has a bug".On Wed, Mar 4, 2020 at 3:43 PM Carlton Gibson <carlto...@gmail.com> wrote:HI Uri.Yes, we know. :) Please don't bump. It's just adds noise. (If you MUST bump, a comment on the PR is more than enough, so not everyone of the thousands on this list needs a notification.) Thanks.Ref backport: it's a possibility but you should phrase it more like, "this is serious bug for any user of i18n supporting non-latin languages"[*] — or similar. (That one user has a bug wouldn't qualify it.) — It is under consideration.
On Wednesday, 4 March 2020 14:20:10 UTC+1, Uri wrote:Django developers,PR #12332 is waiting to be reviewed and approved.I would also like to suggest to include this PR, if accepted, into the next version of 2.2. Otherwise I will not be able to use 2.2 or I will have to fork Django to use 2.2, and then I will have to apply every patch manually to my fork, which is a harass and I don't think should be necessary.
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-d...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CABD5YeGCfRT07uRpM3phmQFpNJz%2BFouKt1N4Ty%3D9tC0-Uz-Bjw%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 django-d...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJwKpyTngRNidxiJXsc7a3McQqtVp-TSjrdWheCq5s6j8r%3DLwg%40mail.gmail.com.