Keep https://code.djangoproject.com/ login
Django developers, https://code.djangoproject.com/ logs me out after about 24 hours, and each time I have to login again (with GitHub). Why doesn't it keep me logged in as long as I'm logged in with GitHub? This is a harass and I think this week I already logged in a few times. אורי u...@speedy.net -- 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/CABD5YeGqEndbYc4nrt5LU9E448%3Di4s0iuPgrD0GG13w3SKa2wQ%40mail.gmail.com.
Re: ngettext_lazy and ngettext
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%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 it would be a cost of having the better
expression for some situations given the design of the software - and
another thing is have to do it in the future without any purpose, because a
broken equation made
Re: Suggestion: required_ancestor relation for plugins.
Hello Jacob, I see that what I need require a lot of knowledge about how Django-CMS work at the javascript frontend level and I'm not there yet. I found a quick work around. My descendant child plugin has a list of ancestors that it can be included in and I get all the parents class name and compare. If the required ancestor is found, I set a variable in the context to true and the template render the plugin. If the required ancestor is *not* found, I set a variable in the context to false and the template render the plugin with an error message that list the required ancestors. Frédéric Le jeudi 23 janvier 2020 23:02:07 UTC+1, Jacob Rief a écrit : > > Hello Frédéric, > this is something I always wanted to implement, because it makes the > configuration of plugins unnecessarily difficult. > Please read this proposal: https://github.com/divio/django-cms/issues/6110 > > If you wonder, why I never implemented it: no spare time/lack of funding. > > Best Regards, > Jacob > > -- Message URL: https://groups.google.com/d/msg/django-cms-developers/topic-id/message-id Unsubscribe: send a message to django-cms-developers+unsubscr...@googlegroups.com --- You received this message because you are subscribed to the Google Groups "django CMS developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-cms-developers+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/django-cms-developers/f0fc15fd-2c5b-47c8-b82c-53f3e7ab4c30%40googlegroups.com.
Re: More standard template filters
There are already filters which works on advance logic. for example :-
'join'. So, is it not good to add filter for startswith, endswith and
contains as well?
On Friday, 5 April 2019 14:46:53 UTC+5:30, Adam Johnson wrote:
>
> FYI Jinja2 allows (most) python expressions, so this would Just Work(TM):
>
> {{ myvar.startswith("x") }}
>
> Django Template Language has a lot of legacy that prevents this from
> happening, afaiu it would not be possible to move to it.
>
> It's not hard to move your templates (asides from those extending external
> packages like the admin) to Jinja2, since the syntax is very similar and
> you can pop a Jinja2 backend in your TEMPLATES.
>
>
>
> On Fri, 5 Apr 2019 at 07:43, Curtis Maloney > wrote:
>
>> On 4/5/19 3:06 AM, Collin Anderson wrote:
>> > Hi All,
>> >
>> > I use django templates a lot and I always wished there was a
>> > myvar|startswith:"teststring", myvar|endswith:"teststring" and a
>> > myvar|contains:"teststring" filter.
>>
>> It's almost like we need a syntax for calling methods with an argument,
>> just like we can with filters.
>>
>> For example (bring on the sheds for bikes!)
>>
>> {{ myvar.startswith<"teststring" }}
>>
>> > I instead do stuff like myvar|slice:":10" == "teststring" which is a
>> > total hack.
>> >
>> > Is this something that could be simple and common enough to add to
>> > django as batteries-included built-in?
>>
>> Alternatively, I recall some time in the past I may have written a
>> "strings" template filter library simply to provide string methods as
>> filters...
>>
>> --
>> Curtis
>>
>> --
>> 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-d...@googlegroups.com .
>> To post to this group, send email to django-d...@googlegroups.com
>> .
>> Visit this group at https://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/a2b323bc-9f60-f4c9-6074-4d103bd6f930%40tinbrain.net
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> 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/b447536a-a5e8-47d9-b06f-75f44ef87abc%40googlegroups.com.
Re: Getting error while running tests for postgis
Actually, this is somewhat on topic as it involves running the Django test
suite.
To solve the failure, add this to your test settings:
PASSWORD_HASHERS = [
'django.contrib.auth.hashers.MD5PasswordHasher',
]
It seems like a bug that that test assumes MD5PasswordHasher.
As for the skipped tests, the skips might be expected. Run runtests.py with
"-v 2" to see the reason.
On Thursday, January 23, 2020 at 2:08:15 PM UTC-5, Pratik kumar wrote:
>
> I was running the test With for GeoDjnago using the following commands
> ./runtests.py --settings=postgis
> with the following settings file
> DATABASES = {
> 'default': {
> 'ENGINE': 'django.contrib.gis.db.backends.postgis',
> 'NAME':'defaultd',
> 'USER': 'user',
> 'PASSWORD':'password',
> 'HOST': '127.0.0.1',
> 'PORT': '5432',
> },
> 'other': {
> 'ENGINE': 'django.contrib.gis.db.backends.postgis',
> 'NAME':'otherd',
> 'USER': 'user',
> 'PASSWORD':'password',
> 'HOST': '127.0.0.1',
> 'PORT': '5432',
> }
> }
> SECRET_KEY = 'django_tests_secret_key'
> Got the following error, can't seem to understand the reason behind it.
> how can i remove it
>
> [image: Screenshot from 2020-01-23 23-54-14.png]
>
>
> Also when i run test specifically for geoDjango there are 13 tests which
> are skipped how to avoid skipping those tests.
>
> Any help will be appreciated
>
--
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/0b0a766d-aed9-4f2c-bb64-43112b2de63e%40googlegroups.com.
Re: Getting error while running tests for postgis
I am working on a ticket need to run tests for postgis, isn't it concerned with the development of django itself? -- 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/2ad5bd90-5fa6-4843-b158-fac0bceef515%40googlegroups.com.
Re: Getting error while running tests for postgis
I'm sorry but you have found the wrong mailing list for this post.
This mailing list is about the development of django itself. If you have
any issues with your code I suggest you ask in any programmers community
like stackoverflow or reddit.
On Thu, Jan 23, 2020 at 8:08 PM Pratik kumar
wrote:
> I was running the test With for GeoDjnago using the following commands
> ./runtests.py --settings=postgis
> with the following settings file
> DATABASES = {
> 'default': {
> 'ENGINE': 'django.contrib.gis.db.backends.postgis',
> 'NAME':'defaultd',
> 'USER': 'user',
> 'PASSWORD':'password',
> 'HOST': '127.0.0.1',
> 'PORT': '5432',
> },
> 'other': {
> 'ENGINE': 'django.contrib.gis.db.backends.postgis',
> 'NAME':'otherd',
> 'USER': 'user',
> 'PASSWORD':'password',
> 'HOST': '127.0.0.1',
> 'PORT': '5432',
> }
> }
> SECRET_KEY = 'django_tests_secret_key'
> Got the following error, can't seem to understand the reason behind it.
> how can i remove it
>
> [image: Screenshot from 2020-01-23 23-54-14.png]
>
>
> Also when i run test specifically for geoDjango there are 13 tests which
> are skipped how to avoid skipping those tests.
>
> Any help will be appreciated
>
> --
> 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/3515bc07-8e53-4c61-8838-e074b36f1b0a%40googlegroups.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/CAD9uRzfLrV4%2BLi2fpNCO73vBwreJGBoACkpz0i3xxpy-vVduGw%40mail.gmail.com.
Getting error while running tests for postgis
I was running the test With for GeoDjnago using the following commands
./runtests.py --settings=postgis
with the following settings file
DATABASES = {
'default': {
'ENGINE': 'django.contrib.gis.db.backends.postgis',
'NAME':'defaultd',
'USER': 'user',
'PASSWORD':'password',
'HOST': '127.0.0.1',
'PORT': '5432',
},
'other': {
'ENGINE': 'django.contrib.gis.db.backends.postgis',
'NAME':'otherd',
'USER': 'user',
'PASSWORD':'password',
'HOST': '127.0.0.1',
'PORT': '5432',
}
}
SECRET_KEY = 'django_tests_secret_key'
Got the following error, can't seem to understand the reason behind it. how
can i remove it
[image: Screenshot from 2020-01-23 23-54-14.png]
Also when i run test specifically for geoDjango there are 13 tests which
are skipped how to avoid skipping those tests.
Any help will be appreciated
--
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/3515bc07-8e53-4c61-8838-e074b36f1b0a%40googlegroups.com.
Suggestion: required_ancestor relation for plugins.
Hello, the parent/child based restriction for plugins is a bit too much restrictive for my use case. I have a suggestion but I'm not sure how to implement it. I'd like some guidance on what to modify to achieve what I want. The idea is to have a required_ancestor to some plugins. For example in an ecommerce situation you would have a Product plugin that would make available a product model so all sub plugins that it would contain know to what product they are related. [Page] => [Body placeholder] => [ProductPlugin Product=5] => [Bootstrap container] => [Row] => [Column] => [ProductImage] [Column] => [ProductDescription] That way, ProductPlugin set the context, we are building a page to display product 5. Then when they are rendered ProductImage and ProductDescription would know what they would need to render (ie image and description for product 5). ProductPlugin can allow any type of plugin. ProductImage and ProductDescription need to have a productplugin somewhere but it's not required to have it as a direct parent. So I'd like to have ProductImage and ProductDescription as available plugins if I clic [+] on the column plugin because there is a ProductPlugin ancestor but if there is no ProductPlugin ancestor it would not be displayed. Is somebody working on this kind of feature ? Can I test/help to make it ? Best regards, Frédéric Roland -- Message URL: https://groups.google.com/d/msg/django-cms-developers/topic-id/message-id Unsubscribe: send a message to django-cms-developers+unsubscr...@googlegroups.com --- You received this message because you are subscribed to the Google Groups "django CMS developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-cms-developers+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/django-cms-developers/ec28b78b-1124-4352-80c9-976f2b868287%40googlegroups.com.
Re: Feature request: AbstractPermission and AbstractGroup models
You can leave your comments on the discussion that is attached to the ticket, there is no need to start a new one. -- 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/c4827a34-f9b2-412c-a4b1-23e292b85f56%40googlegroups.com.
Re: Feature request: AbstractPermission and AbstractGroup models
Yes I saw this ticket before requesting the feature but I don't know at which state this ticket is (is it in progress ? do they need help ? Will it be even possible ? Will it be done and integrated to Django ?) I'm aware with other solutions such as doing a OneToOne relation but in my opinion it is not clean. It would be like Group having a relation to a GroupMeta model :-/. That means each time I need data from the GroupMeta, I have to go through the relation to be able to retrieve the data I need. This is maybe maniac from me but well, I like clean things. (Even though from your point of view, implementing this in Django is not clean a tall). What are your suggestion(s) ? Le jeudi 23 janvier 2020 14:41:58 UTC+1, Mariusz Felisiak a écrit : > > Please check ticket 29748 [1] and a previous discussion [2]. > > [1] https://code.djangoproject.com/ticket/29748 > [2] > https://groups.google.com/forum/#!topic/django-developers/llQJZUKejXg/discussion > -- 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/1049e216-b542-4a31-984f-25d2149dfe81%40googlegroups.com.
Re: Feature request: AbstractPermission and AbstractGroup models
Please check ticket 29748 [1] and a previous discussion [2]. [1] https://code.djangoproject.com/ticket/29748 [2] https://groups.google.com/forum/#!topic/django-developers/llQJZUKejXg/discussion -- 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/a1fb33ab-9b50-49fa-b409-32c1c8f3cefd%40googlegroups.com.
Feature request: AbstractPermission and AbstractGroup models
Hi everyone. As it is possible to customize the User model using AbstractUser or AbstractBaseUser, it would be great to be able to do the same with groups and permissions. The goal is to provide 2 new abstract models "AbstractGroup" and "AbstractPermission", in order to benefit from all the already-developed stuff around these models. In addition to these 2 new models, 2 new settings would come with : AUTH_GROUP_MODEL AUTH_PERMISSION_MODEL to achieve the customization as it is possible to do with the User. All of this would be great in order to enable developers to customize their models by adding new fields to them for instance. I hope you will get the interest of it. I'm open to discussions about that. -- 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/5711b52e-78ec-401b-88b6-de4d0b96%40googlegroups.com.
