On Fri, Jan 24, 2020 at 2:17 AM Matemática A3K
wrote:
>
>
> On Fri, Jan 10, 2020 at 8:38 PM Matemática A3K
> wrote:
>
>> 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-time
>> 2- 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=.txt
>>
>> For 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 my surprise, yesterday when I started to work again in this issue - I
> thought we had agreed for a review after the code was separated in commits
> - I saw that the ticket was disowned from me.
>
> So, I will leave my thoughts here.
>
> I think the discussion hasn't been the best, both in constructiveness and
> fluidity terms, but as I had committed to get this fixed, I have continued
> working to get the best for it despite the differences.
>
> I will write my concerns about the accepted fix ("dict-merge" policy).
>
> - Users may be left in an unsatisfactory situation
>
> Plural forms only get to the users' catalogs once it is created by
> makemessages. Once that a catalog is "filled", it is not safe to just
> update plural forms as it may require content modification.
>
> Given that broken (buggy) plural forms have been distributed with Django,
> those catalogs will remain broken and unnoticed under the "dict-merge"
> policy.
>
> The only rationale that I can think of for justifying this is "If they
> don't see anything broken and they are happy with it, it doesn't matter".
>
> This is not acceptable for me, you should choose under the full
> understanding of the situation. If you are happy with it, you may choose
> the situation.
> for it.
>
> If there is another justification, it hasn't been answered the several
> times that I asked for it.
>
> The broken plural forms are mostly broken equations that will never
> evaluate to that forms, making wasting effort. One thing is completing
> plural forms for adhering to an standard which will give a better
> expression in some cases - where i
