Re: ngettext_lazy and ngettext

[Matemática A3K]

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 :)

On Mon, Jan 6, 2020 at 4:17 PM Matemática A3K 
wrote:

>
>
> On Fri, Dec 13, 2019 at 1:04 AM Matemática A3K 
> wrote:
>
>>
>>
>> On Fri, Dec 6, 2019 at 2:14 AM Matemática A3K 
>> wrote:
>>
>>>
>>>
>>> On Thu, Dec 5, 2019 at 4:23 PM Maciek Olko 
>>> 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
>>>
>>
>> Under this rationale, this would be the fix:
>>
>> .. _plural-forms:
>>
>> Plural Forms
>> 
>>
>> Django does not support multiple plural forms in catalogs. As all
>> translation
>> catalogs are merged, only the plural form in the main Django po file
>> (located in
>> ``django/conf/locale//LC_MESSAGES/django.po``) is considered.
>>
>> Plural forms in all other po files are ignored by the GNU gettext merging
>> process.
>>
>> Therefore, you shouldn't use different plural forms in your project or
>> application
>> po files, as it may lead to unexpected results.
>>
>> To prevent inconsistencies and undesired behaviors in translations,
>> Django will
>> not merge any catalog that contains a different plural form than the main
>> one
>> and will issue a warning about the conflicting catalog.
>>
>> This conflict may arise mostly in two situations:
>>
>> * when the main plural form for a language is updated
>> in Django and your po files were generated with a previous one, or
>> * when including third-party translations with a different plural form.
>>
>> Django follows the standards provided by `Unicode
>> <
>> http://www.unicode.org/cldr/charts/latest/supplemental/language_plural_rules.html
>> >`_
>> for plural equations for each language, 

Re: Worth raising a warning when `order_by('?')` is used with specific backends?

[Santiago Basulto]

👍 ok, great. They're both good points. As to Adam's point about missing
warnings: it is true, they can be missed, but there are ways to enforce
them (python -W error, or PYTHONWARNINGS=error).

On Fri, Jan 10, 2020 at 12:41 PM Tim Graham  wrote:

> I think issuing a warning would be rude to developers who want to use that
> feature and are aware of the limitation... they would have to do extra work
> to silence the warning.
>
> On Friday, January 10, 2020 at 10:14:23 AM UTC-5, Santiago Basulto wrote:
>>
>> Sadly I have to admit that I'm not involved with day to day development
>> of our app anymore (I miss it tremendously). Yesterday I felt nostalgic and
>> reviewed a few already-merged PRs, just "for fun" we could say. Great was
>> my surprise when I noticed that one of those PRs was merged with an
>> `order_by('?')`. We're (and we've always been) using Postgres, and I knew
>> already that `ORDER BY RANDOM()` is very slow. I just submitted a comment
>> and it's already been fixed, so it wasn't a big deal. But this got me
>> thinking:
>>
>> TLDR;
>> Some less-experienced developers might not know the issues with
>> `order_by('?')` (at least with Postgres, the only engine I'm familiar
>> enough) and it's worth raising a warning. I don't know what's the state of
>> other engines, it's maybe even worth raising the issue for ANY engine.
>>
>> It could help newcomers catch these issues early. The docs clearly state
>> it
>> ,
>> but not everybody reads the docs with such level of detail:
>>
>> Note: order_by('?') queries may be expensive and slow, depending on the
>>> database backend you’re using
>>
>>
>> PS: Sorry for the personal touch of this message, but I think it's worth
>> the explanation.
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/django-developers/WdkpBmN6XRc/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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/d11f0f8c-a73f-4e95-9b69-25d3195effb8%40googlegroups.com
> 
> .
>


-- 
Santiago Basulto.-
Up!

-- 
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/CAPmap1eMp8k%2B9nJvdr0bDz%2BwYeWCQFiNde-dgvMY7WBoS9P-xQ%40mail.gmail.com.

Re: Worth raising a warning when `order_by('?')` is used with specific backends?

[Tim Graham]

I think issuing a warning would be rude to developers who want to use that 
feature and are aware of the limitation... they would have to do extra work 
to silence the warning.

On Friday, January 10, 2020 at 10:14:23 AM UTC-5, Santiago Basulto wrote:
>
> Sadly I have to admit that I'm not involved with day to day development of 
> our app anymore (I miss it tremendously). Yesterday I felt nostalgic and 
> reviewed a few already-merged PRs, just "for fun" we could say. Great was 
> my surprise when I noticed that one of those PRs was merged with an 
> `order_by('?')`. We're (and we've always been) using Postgres, and I knew 
> already that `ORDER BY RANDOM()` is very slow. I just submitted a comment 
> and it's already been fixed, so it wasn't a big deal. But this got me 
> thinking:
>
> TLDR;
> Some less-experienced developers might not know the issues with 
> `order_by('?')` (at least with Postgres, the only engine I'm familiar 
> enough) and it's worth raising a warning. I don't know what's the state of 
> other engines, it's maybe even worth raising the issue for ANY engine.
>
> It could help newcomers catch these issues early. The docs clearly state 
> it 
> ,
>  
> but not everybody reads the docs with such level of detail:
>
> Note: order_by('?') queries may be expensive and slow, depending on the 
>> database backend you’re using
>
>
> PS: Sorry for the personal touch of this message, but I think it's worth 
> the explanation.
>

-- 
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/d11f0f8c-a73f-4e95-9b69-25d3195effb8%40googlegroups.com.

Re: Worth raising a warning when `order_by('?')` is used with specific backends?

[Adam Johnson]

Hi Santiago

There are any kinds of queries that can be slow in Django. ORDER BY
RANDOM() will be just as slow on large tables as ORDER BY
some_unindexed_column, or many other SQL constructs.

Django can't predict well how expensive a query will be - that's the job of
the database's optimizer. It varies on many factors that only the database
server knows - table size, index size, column histograms, etc.

I therefore don't think such a warning would be very accurate or useful.

(Also, just as documentation can be missed, so too can warnings.)

Thanks,

Adam

On Fri, 10 Jan 2020 at 15:14, Santiago Basulto 
wrote:

> Sadly I have to admit that I'm not involved with day to day development of
> our app anymore (I miss it tremendously). Yesterday I felt nostalgic and
> reviewed a few already-merged PRs, just "for fun" we could say. Great was
> my surprise when I noticed that one of those PRs was merged with an
> `order_by('?')`. We're (and we've always been) using Postgres, and I knew
> already that `ORDER BY RANDOM()` is very slow. I just submitted a comment
> and it's already been fixed, so it wasn't a big deal. But this got me
> thinking:
>
> TLDR;
> Some less-experienced developers might not know the issues with
> `order_by('?')` (at least with Postgres, the only engine I'm familiar
> enough) and it's worth raising a warning. I don't know what's the state of
> other engines, it's maybe even worth raising the issue for ANY engine.
>
> It could help newcomers catch these issues early. The docs clearly state
> it
> ,
> but not everybody reads the docs with such level of detail:
>
> Note: order_by('?') queries may be expensive and slow, depending on the
>> database backend you’re using
>
>
> PS: Sorry for the personal touch of this message, but I think it's worth
> the explanation.
>
> --
> 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/fe948733-7767-4688-b89a-43fa57153905%40googlegroups.com
> 
> .
>


-- 
Adam

-- 
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/CAMyDDM3bpFfk48HBMy%2BvjZJ_6v-jKB2xhtvtoe%3DjMh_SttjyqQ%40mail.gmail.com.

Worth raising a warning when `order_by('?')` is used with specific backends?

[Santiago Basulto]

Sadly I have to admit that I'm not involved with day to day development of 
our app anymore (I miss it tremendously). Yesterday I felt nostalgic and 
reviewed a few already-merged PRs, just "for fun" we could say. Great was 
my surprise when I noticed that one of those PRs was merged with an 
`order_by('?')`. We're (and we've always been) using Postgres, and I knew 
already that `ORDER BY RANDOM()` is very slow. I just submitted a comment 
and it's already been fixed, so it wasn't a big deal. But this got me 
thinking:

TLDR;
Some less-experienced developers might not know the issues with 
`order_by('?')` (at least with Postgres, the only engine I'm familiar 
enough) and it's worth raising a warning. I don't know what's the state of 
other engines, it's maybe even worth raising the issue for ANY engine.

It could help newcomers catch these issues early. The docs clearly state it 
,
 
but not everybody reads the docs with such level of detail:

Note: order_by('?') queries may be expensive and slow, depending on the 
> database backend you’re using


PS: Sorry for the personal touch of this message, but I think it's worth 
the explanation.

-- 
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/fe948733-7767-4688-b89a-43fa57153905%40googlegroups.com.

Re: GDAPS

[Christian González]

Am 08.01.20 um 22:39 schrieb Aymeric Augustin:
The original intent was to make configuration explicit by having 
settings.py reference directly the target AppConfig class.


- When you write MIDDLEWARE = ["polls"], do you expect Django to 
enable "polls.middleware.PollsMiddleware"?
- When you write INSTALLED_APPS = ["polls"], do you expect Django to 
enable "polls.apps.PollsAppConfig"?


Many readers of this mailing list will answer "no" and "yes" 
respectively. I think the answer to both should be "no", according to 
Django's design philosophy 
. 
(If you're about to argue that an application can provide more than 
one middleware — I'm aware of this and I know you understood my point 
anyway.)

Yes, that's exactly what I wanted to state.

[...]

If we're reversing course, giving up on explicitness and going for 
magic, we could embrace that decision fully: import the "apps" 
submodule inside each application; if it exists and it defines exactly 
one AppConfig subclass, use that as the config for this app. Then app 
authors can stop littering their __init__.py files with 
default_app_config.


That would be perfect IMHO. One could consider restricting it to the 
same-named subclass like the app itself, so the app "foo" would need to 
have "FooConfig" as default.


I'm aware that this violates the 2nd "Zen of Python" principle "Explicit 
is better than implicit". and "Special cases aren't special enough to 
break the rules." - but the next one says: "Although practicality beats 
purity."


Yes, too much "magic" leads to a system where half of it uses magic, and 
the other half not - so it's not predictable for the developer what a 
certain line does.


But exactly in this part I think that having a "sane default" - in the 
sense of app loading using by using the app name only - is ok.


I would bet that the vast majority of apps don't have two AppConfigs.
And to urge all devs to use the more elaborative AppConfig line in 
INSTALLED_APPS, just to make such special cases (and THESE are the 
special cases!) are possible, is wrong IMHO.


Let it be easy - even the variable says INSTALLED_APPS, not 
INSTALLED_CONFIGS. And let there be the *possibility *to declare other 
AppConfigs on demand.


Christian


--
Dr. Christian González
https://nerdocs.at

--
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/b37e3655-4253-75a1-b750-6c81a0f6cf26%40nerdocs.at.