On Tue, Nov 26, 2019 at 12:51 PM Shai Berger <s...@platonix.com> wrote:
> On Tue, 26 Nov 2019 12:28:45 +0100 > Maciek Olko <maciej.o...@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 correct Giving 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? > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/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-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CA%2BFDnhJcBRBie-pwySwJMUUuUNZ3eQoG%2BSPogvmJjC%2Bsn1c4Hw%40mail.gmail.com.
