On Fri, Dec 6, 2019 at 2:14 AM Matemática A3K <matematica....@gmail.com> wrote:
> > > On Thu, Dec 5, 2019 at 4:23 PM Maciek Olko <maciej.o...@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 > > >> >> Especially 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 >> . >> > Yes, there seems to be a source for errors there, because the Transifex front-end shows the entries according to the plural form of the file, maybe when it was built they were assumed to be individual catalogs not to be merged with others (there is no "project" or "group" constrain). If the plural form says 3 plurals, it will be considered as a valid submit - and it is according to the pf - but once it gets merged with a 4-plurals catalog, it will break if there is pluralization in it (as it has happened before). A solution for this is to use the Unicode plural form for the language in each catalog on Transifex, it seems that this has to be set manually. In the same direction, these seems broken: https://github.com/django/django/blob/master/django/contrib/sessions/locale/kn/LC_MESSAGES/django.po https://github.com/django/django/blob/master/django/contrib/sessions/locale/kk/LC_MESSAGES/django.po and they use a main PF of 'nplurals=2; plural=(n!=1);' and 'nplurals=2; plural=(n > 1);', There should be an agreement also of how to express the rules in the equations in order to be able to detect inconsistencies easier. Note that as the contrib.sessions catalog does not contain any pluralized strings the error goes in-adverted. If Django adopts the Unicode standard as official for its plural forms, then they shouldn't be changed unless the standard changes - and that should make it to the Release Notes. That would be the first step for getting the Django catalog consistent and "PF-stable", making easier for third-parties to build upon them. If there is an agreement, those have to been updated by the Django Translators Teams, because it seems that there is no enforcement or constrains in the Transifex front-end about PFs for a language, otherwise catalogs like Slovak, Lithuanian and Ukranian in contrib.sessions wouldn't have a non-Unicode PF (see Inconsistencies in Catalogs). >> Regards, >> Maciej >> >> czw., 5 gru 2019 o 08:00 Matemática A3K <matematica....@gmail.com> >> napisał(a): >> >>> While testing the "not-merging" policy, I got this: >>> https://pastebin.com/ihyAiYtc >>> Those warnings should get to the Translators teams if they are not >>> looking here, i.e. >>> >>> https://github.com/django/django/blob/master/django/contrib/sessions/locale/he/LC_MESSAGES/django.po >>> is still using a 2-plurals form in a 4 plural form - it doesn't matter >>> in this case because there are no translations with plurals, but they >>> trigger the warning because the pf hasn't been updated and they should if >>> the Transifex front-end use the pf of a file for showing the options for >>> translating and to be inline with the main form. >>> >>> >>> On Thu, Dec 5, 2019 at 12:10 AM Matemática A3K <matematica....@gmail.com> >>> wrote: >>> >>>> >>>> >>>> On Wed, Dec 4, 2019 at 2:25 AM Claude Paroz <cla...@2xlibre.net> wrote: >>>> >>>>> Le mercredi 4 décembre 2019 03:41:51 UTC+1, Matemática A3K a écrit : >>>>>> >>>>>> (...) >>>>>> >>>>>> 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. >>>>>> >>>>> >>>>> Sorry, I'm not following you here. The catalog merge process is >>>>> happening in realtime when Django starts, so any po file update is >>>>> instantly reflected in the translation infrastructure. I don't see any >>>>> caveat here. >>>>> >>>> >>>> Yes, but only for the default language, the rest are lazily loaded on >>>> demand - this is why I think it is better do the check at a system level, >>>> if you have more than a language available, the others will be merged for >>>> loading them once something triggers it (like an >>>> "activate("LANGUAGE_CODE")) and only there you would start to see the >>>> warnings. >>>> >>>> For the example of the caveat of the dict-merging, it would be like >>>> this: >>>> >>>> - Someone starts its translation with Django 2.2 for Hebrew via >>>> makemessages, which copies the main plural form to the new file, and fills >>>> the translations. >>>> - The user upgrades to Django 2.2.x or up, which contains a fixed >>>> plural form for Hebrew >>>> - Under the "dict-merge" policy, the Django translation catalog would >>>> have 2 entries, one for the main plural form (the new one) and other the >>>> catalog generated in the past (the user's one). >>>> >>>> Strings in the user catalog would use a "worse" plural equation, while >>>> strings in the Django catalog will use the better one. Updates won't reach >>>> to users' catalogs, unless they explicitly update them, because once the >>>> user's po is created, makemessages won't update the header, it will do a >>>> msgmerge ( >>>> https://github.com/django/django/blob/master/django/core/management/commands/makemessages.py#L603 >>>> ). >>>> >>>> That's why something like "makemessages --update-plural-form" and a >>>> warning about different plurals forms in the catalog would be needed, even >>>> under "dict-merge". >>>> >>>> With the current "merge" policy, because only the main form used, the >>>> users would get the update but they won't be able to have parts of the >>>> catalog under a different pf. >>>> >>>> The way to have a different plural form than the main one with the >>>> current code base would be by having a custom variant of the language >>>> (which implements "the spirit of dict-merge": independent catalogs with an >>>> order of precedence). It's not ideal, you will loose the ability of using >>>> the browser's locale config to display the language out of the box unless >>>> you add extra code to handle it, something like "if locale == 'he': use >>>> 'he_SP'" (no other caveat comes to my mind). But it would be they way of >>>> having it RN without loosing the updates. >>>> >>>> >>>>> >>>>> 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-developers+unsubscr...@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 >>>>> <https://groups.google.com/d/msgid/django-developers/5f2bf52a-997c-467d-b927-f2959507d32e%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >>> 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%2BFDnhKtEB4sgUFwmyaExGLSnMU5yLkj0QZ1ubpF2gaRjBd1EQ%40mail.gmail.com >>> <https://groups.google.com/d/msgid/django-developers/CA%2BFDnhKtEB4sgUFwmyaExGLSnMU5yLkj0QZ1ubpF2gaRjBd1EQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> 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/CALYYG80tyJdmEw1LJaV0sa6OHQ0HMkecO2wsHJkvvyQ4%3DT0Tzw%40mail.gmail.com >> <https://groups.google.com/d/msgid/django-developers/CALYYG80tyJdmEw1LJaV0sa6OHQ0HMkecO2wsHJkvvyQ4%3DT0Tzw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- 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%2BFDnhLYwbS%2BERrt%3DQkc2ZFE%2Bbuz-xO8yfLr6Obpy2VNaRnFiA%40mail.gmail.com.
