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