Re: Can we make HTTP 308 the default for CommonMiddleware / APPEND_SLASH?

2019-01-11 Thread George-Cristian Bîrzan
I completely agree.

Even without getting into API clients, the intent of this option is to tell
everyone that the canonical URL is not that, not disrupt normal operations.
The same can be said about the http->https redirect. There's no security
problem here, as the data has already been sent in plain text, the only
thing that I can think of is whether HSTS preload will support anything
except 301.

I can, however, see a downside, mostly for API clients, but the people that
use the APPEND_SLASH option obviously don't care about this aspect, which
is that API clients generally don't cache 301s between sessions, so every
request will have an extra hop, vs realising instantly that it's broken
(because your POST doesn't work). However, this is something you should
expect, after you set that option.

As a side note, this is the browser support for 308:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/308#Browser_compatibility
- IE on Windows 7/8.1 doesn't support it. User agent hacks are bad, but, at
least as a setting that (temporarily) defaults to off this would be a huge
improvement.

On Fri, 11 Jan 2019 at 19:25, René Fleschenberg 
wrote:

> I am using ``APPEND_SLASH = True`` (the default) and usually use a
> trailing slash in all of my URL patterns.
>
> This works great for the most part, but some API clients send
> POST-requests without the slash and then change the request method to
> GET on the subsequent request. In particular, a popular API testing tool
> (https://www.getpostman.com/) seems to be affected by this.
>
> I can subclass ``CommonMiddleware`` and set ``response_redirect_class``,
> no problem. However, maybe Django should just send HTTP 308 by default?
> Is there any reason not to?
>
> --
> René Fleschenberg
>
> --
> 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 post to this group, send email to django-developers@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/1aa24da3-cd05-317a-b8c1-2a76d707b935%40fleschenberg.net
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
George-Cristian Bîrzan

-- 
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 post to this group, send email to django-developers@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/CAMxNYaaNdN4oQrQa6csWt_TWE2onShXSrYBfp-CF2ta%2Bunptdg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Can we make HTTP 308 the default for CommonMiddleware / APPEND_SLASH?

2019-01-11 Thread René Fleschenberg
I am using ``APPEND_SLASH = True`` (the default) and usually use a
trailing slash in all of my URL patterns.

This works great for the most part, but some API clients send
POST-requests without the slash and then change the request method to
GET on the subsequent request. In particular, a popular API testing tool
(https://www.getpostman.com/) seems to be affected by this.

I can subclass ``CommonMiddleware`` and set ``response_redirect_class``,
no problem. However, maybe Django should just send HTTP 308 by default?
Is there any reason not to?

-- 
René Fleschenberg

-- 
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 post to this group, send email to django-developers@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/1aa24da3-cd05-317a-b8c1-2a76d707b935%40fleschenberg.net.
For more options, visit https://groups.google.com/d/optout.


Re: Request to reconsider ticket #27910: using an Enum class in model Field choices

2019-01-11 Thread James Bennett
Shai, your rebuttal still misses an important use case, which is
containment.

To continue with your example of a 'SchoolYear(str, Enum)', the following
will both be False:

'FR' in SchoolYear
'FR' in SchoolYear.__members__

The first of those is also becoming illegal soon -- attempting an 'in'
comparison on an Enum, using an operand that isn't an instance of Enum,
will become a TypeError in Python 3.8.

Instead you have to do something like:

'FR' in [choice.value for choice in SchoolYear]

to get a containment check. And you need a containment check to perform
validation.

There are other ways to do it, but they're all clunky, and this is going to
be code that people have to write (in some form) over and over again,
unless we build our own choice abstraction that hides this by wrapping an
Enum and implementing a __contains__ that does what people want. And you'd
basically have to do it in a wrapper, because Enum does metaclass stuff
that interferes with a typical "just subclass and override" approach.

So I still don't think this is going to work for the model-choice use case
without a lot of fiddling (and I'm still not a fan of the enum module in
general, largely because it seems to have gone out of its way to make this
use case difficult to implement).

-- 
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 post to this group, send email to django-developers@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/CAL13Cg_KEtgmNzRo%3DC8cnCiNsukr5YOCTv3MF8AybV%3D%3DiUXP0g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: Request to reconsider ticket #27910: using an Enum class in model Field choices

2019-01-11 Thread Luke Plant
I've also tried to come up with something better than Django's current 
default, using Enums, and found them lacking when it comes to the 
caption, especially when you need translations.


I would be happy with re-opening the ticket, but in terms of committing 
a solution I would be -1 unless we can find something which is 
definitely significantly better than the status quo, which the majority 
of people would want to use, rather than just an alternative - something 
that we would be happy to be become the recommended default and present 
in the docs as such. Otherwise we just have 2 ways to do it.


I quite like Tom's suggestion here:

https://code.djangoproject.com/ticket/27910#comment:6

It's not perfect but seems a reasonable compromise given the constraints.

Luke


On 11/01/2019 14:55, Shai Berger wrote:

On Mon, 31 Dec 2018 23:40:53 +
Tom Forbes  wrote:

We currently have a -1 and a +1, does anyone else have any input on
this?


So, the tally is +3, -1, and the -1 seems to be based on a technical
argument which I believe I refuted; and more than a week has passed
with no further comment.

Looks to me like at least a rough consensus of "eh, ok, if you really
want it..."



--
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 post to this group, send email to django-developers@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/f0677170-65d9-d1bb-9b3f-da7c494acb6d%40cantab.net.
For more options, visit https://groups.google.com/d/optout.


Re: Request to reconsider ticket #27910: using an Enum class in model Field choices

2019-01-11 Thread Shai Berger
On Mon, 31 Dec 2018 23:40:53 +
Tom Forbes  wrote:
> 
> We currently have a -1 and a +1, does anyone else have any input on
> this?
> 

So, the tally is +3, -1, and the -1 seems to be based on a technical
argument which I believe I refuted; and more than a week has passed
with no further comment.

Looks to me like at least a rough consensus of "eh, ok, if you really
want it..."

-- 
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 post to this group, send email to django-developers@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/2019035554.08a7e45d.shai%40platonix.com.
For more options, visit https://groups.google.com/d/optout.


Re: thoughts for Django fellowship applicants

2019-01-11 Thread Carlton Gibson


> On 10 Jan 2019, at 20:16, Adam Johnson  wrote:
> 
> It will be hard for any new fellow to match you.


I go for “aspire to…” 

-- 
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 post to this group, send email to django-developers@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/0803A9CC-2493-4904-A5AC-A59ACFD9159E%40gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: makemessages - Add an option to disable fuzzy translations?

2019-01-11 Thread Sjoerd Job Postmus
Regarding the "default keyword TODO": there are tools that can be used 
for working with translations, in the gettext suite.



For instance, for a given django.po file, the following command prints 
all untranslated strings:



    msgattrib --untranslated path/to/django.po


We have the following command somewhere in a wiki:


    for k in */locale/*/LC_MESSAGES/django.po; do echo $(msgattrib 
--untranslated $k | grep msgstr | wc -l) $k; done | grep -v '^0 ' | sort -n


which prints the files with missing translations, together with how many 
translations are missing.




Unrelated tips for makemessages, but if you start overriding 
makemessages, good extra flags would be:


* just hard-code `no_location` to True. It makes the generated .po-file 
non-stable when adding even 1 extra line in the source file.


* same for hard-coding `no_wrap` to be honest, *or* the line-width.

* "--sort-output" (for msgmerge and msgattrib), so that the generated 
.po-file is stable, even when the code itself has been moved around.


* add the flag "--keyword=_l", so that you can use `_l` instead of 
`gettext_lazy`, but that's depending on taste.


Regards,

Sjoerd Job


On 11/01/2019 07:42, אורי wrote:

https://code.djangoproject.com/ticket/10852

I also don't like the "fuzzy" keyword and I spent hours in deleting 
them from our django.po files after running makemessages. I would like 
to disable them completely since they don't make sense in our project. 
Every time after running makemessages I have to search for the "fuzzy" 
keywords, delete them and also delete translations which are 
incorrect. I would like all the translations to be blank if not 
exactly translated.


I didn't understand what you mean by "msgmerge with the "-N" option 
swiches off fuzzy-matching.".


By the way, is it possible to add a default keyword that will be used 
for all new translations instead of "" in a specific language? 
For example "TODO"? Because I don't want to forget to translate them. 
Currently I have to search and manually replace "" with "TODO". And by 
the way the string "" appears also with translated texts.


Thanks,
אורי (Uri)
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 post to this group, send email to 
django-developers@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/CABD5YeHU68Vr9M%2BMCvb3DiJYUpBUaO2PJuEpXb%3DctqE1HJX4fQ%40mail.gmail.com 
.

For more options, visit https://groups.google.com/d/optout.


--
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 post to this group, send email to django-developers@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/6082c7ef-e39c-3109-3bcf-dd19ef6f7bad%40sjec.nl.
For more options, visit https://groups.google.com/d/optout.


Re: makemessages - Add an option to disable fuzzy translations?

2019-01-11 Thread Claude Paroz
Le vendredi 11 janvier 2019 07:46:04 UTC+1, Uri Even-Chen a écrit :
>
> https://code.djangoproject.com/ticket/10852
>
> I also don't like the "fuzzy" keyword and I spent hours in deleting them 
> from our django.po files after running makemessages. 
>

Hi Uri,

Create your own makemessages command and provide your custom 
msgmerge_options. Something like:

from django.core.management.commands.makemessages import Command as 
MakeMessagesCommand

class Command(MakeMessagesCommand):
msgmerge_options = ['-q', '--previous', '--no-fuzzy-matching']

As for your second question, your should use a dedicated tool to translate 
messages (poedit, gtranslator, virtaal, lokalize, etc.), so you won't have 
to search for untranslated messages yourself. Even text editors like vim or 
emacs provide po mode translations.

HTH,

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 post to this group, send email to django-developers@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/285f2dea-2a2a-472f-83ad-0c06c4471026%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.