Le lundi 23 juillet 2018 21:17:24 UTC+2, Claude Paroz a écrit :
> I'll see if I can add subresource integrity support to demonstrate a
> potential added value.
>
Just for feasibility's sake, here's a quick (and probably dirty) way to
implement subresource integri
Hi Deniz,
Please do not cross-post your issues over several mailing lists, we are
already talking about your issue in gnome-i18n. Thanks.
https://groups.google.com/forum/#!topic/django-i18n/xSlv7gD7F4Y
Claude
Le lundi 13 août 2018 01:59:14 UTC+2, Deniz Bazan a écrit :
>
> Dear Django Developers
Le vendredi 24 août 2018 11:35:43 UTC+2, Jamesie Pic a écrit :
>
> Thank for your feedback.
>
> It's the eternal misunderstanding of django's pattern, confusion between
> table, and model, model is de factores what couples table and form, I've
> posted articles about it already. I call this the e
Le dimanche 26 août 2018 13:36:41 UTC+2, James Bennett a écrit :
>
> The only use case for pickle that I'm aware of is "I need a way to add a
> security hole to my site". So let's just get rid of it.
>
Out of memory, I think they were cases when some types were not
JSON-serializable.
Claude
-
Hi Osama,
You can simply do that by including a gettext_noop('your custom string')
line anywhere in your code (or in a specific file you create for that
purpose).
Regards,
Claude
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions
We are not talking about general data encodings here, FILE_CHARSET is used
to read Django text files from disk (template files, static files (css, js)
or translation catalogs). So the question is mainly about encoding usage in
text editors.
Claude
--
You received this message because you are
Le mardi 30 octobre 2018 03:54:42 UTC+1, adson@gmail.com a écrit :
>
> Hi,
>
> I'm starting to work with Django now and would like to contribute to the
> community, but I have not seen any related contribution topics on
> translating documentation to other languages.
>
Here it is:
https://do
Le jeudi 1 novembre 2018 15:37:21 UTC+1, charettes a écrit :
>
> FWIW it looks like gettext support issues were addressed a while ago[0]
>
For the .format() syntax, yes. For f-strings, I'm not sure they can be
internationalized at all. PEP 498 has not a word about it.
Claude
--
You received th
Le jeudi 13 décembre 2018 09:17:49 UTC+1, Carlton Gibson a écrit :
>
> ...
> I'd like to push on these avenues (and similar) before we take on the
> massive project of changing systems.
> (Ultimately I think we'd change system and find ourselves in exactly the
> same boat.)
>
Thanks Carlton, I
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
I understand my obsession for stable software puts me in a small-minority
group and I would not like to be an obstacle for all other Django users and
developers.
Let's stick to the current policy. I'll try to remember that and prevent
commenting on the next " Drop python support..." ticket :-)
Le mercredi 23 janvier 2019 08:31:17 UTC+1, James Bennett a écrit :
>
> I worry about the precedent we'd set if we made an exception for Debian,
> because the next question would be "OK, can we have an exception for Red
> Hat, too?" Keep in mind Red Hat currently sells up to fourteen years of
>
d in?
>
> Do you think it might make a good GSoC project?
>
> C.
>
> On Monday, 23 July 2018 17:36:05 UTC+2, Claude Paroz wrote:
>>
>> Hi,
>>
>> I just created a new feature request [1] to be able to define static
>> files per application, including
Hi,
The new watchman-based autoreloader in Django 2.2 is a nice improvement.
However, the main issue in my opinion is that there are no Debian/Ubuntu
official packaging of watchman to my knowledge.
I've been able to compile it without difficulty, but I'm especially
concerned about newcomers and
Le jeudi 21 février 2019 19:48:31 UTC+1, Dan Davis a écrit :
>
> Claude,
>
> I've tested a Django based application on 2.2b1 without watchman on
> Windows, it does tell you about watchman, but it doesn't fail to run.
> Apparently, it falls back to the old way of reloading. Is this not the
> b
I have a POC patch here: https://github.com/django/django/pull/11014
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
ooks like pyinotify is dead. Tell me
if you need help, even if you seems a lot more knowledgeable than me on the
subject.
Thanks.
Claude
> On Thu, 21 Feb 2019, 19:56 Claude Paroz, >
> wrote:
>
>> Le jeudi 21 février 2019 19:48:31 UTC+1, Dan Davis a écrit :
>>>
>&g
Thanks Joe for this proposal. Unfortunately, I fear it does not play well
with our current workflow, where we download files produced by Transifex.
Could you give us an example where an error revealed by this linter could
improve the quality of the resulting translations?
Claude
--
You receive
Please create a new ticket (where you can reference the original one).
If you can provide a failing test case, it would be great.
Claude
Le lundi 15 avril 2019 13:40:53 UTC+2, Melvyn Sopacua | 3YOURMIND a écrit :
> Hi,
>
> I've added a comment on the commit:
> https://github.com/django/django/c
tion that adds a char or text field with a default
> value. The migration it self will go through, but sqlmigrate will fail.
>
> I'll look into testcasing that.
>
> On Mon, Apr 15, 2019 at 3:25 PM Claude Paroz > wrote:
>
>> Please create a new ticket (where you c
I must admit I'm rather pleased by Luke's proposal. Let's keep our current
isort/flake8 checks and relax other policies (considering the committer can
always minor edit patches, as Tim did in the past).
I'm always a bit suspicious of tools that decide the formatting for me.
Claude
--
You rece
Le samedi 20 avril 2019 09:11:24 UTC+2, Carlton Gibson a écrit :
>
>
>
> On Friday, 19 April 2019 20:33:13 UTC+2, Mariusz Felisiak wrote:
>>
>>
>> I don't think that our code style is any barrier for newcomers. ...we've
>> never blocked any patch due to stylistic nitpicks. I also don't believe
Sorry but I would *strongly* oppose any idea of closing a ticket because
noone commented in the last x years. Most of those tickets are still valid
issues, but they remain open because noone dedicated the appropriate time
to solve them, sometimes because the problem is a corner case, sometimes
Hi,
There is a specific group dedicated to translation issues:
django-i...@googlegroups.com
Please write to that group.
Claude
Le mardi 15 octobre 2019 13:40:38 UTC+2, Soyuzbek orozbek uulu a écrit :
>
> Hi all,
> I want to translate Django to Kyrghyz language using transifex. I already
> sent
Hi,
Could you please tell us a bit more about what the specs say about numbers
in the top-level domain?
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 rece
Hi Uri,
I think you did not understand well the problem. Let me try to explain it
in more details.
Nothing was changed with "ngettext" or "ngettext_lazy" in Django. The
plural equation for Hebrew was changed on the Transifex platform and those
changes reach Django each time we synchronize tran
Le mercredi 6 janvier 2016 19:34:07 UTC+1, Tim Graham a écrit :
>
> The current pull request proposes to make a backwards-incompatible change
> by chopping off any ".tpl" suffix in app or project template files. i.e.
> "If you are using custom templates and these templates already use a
> ``.tpl
Le lundi 22 février 2016 13:00:31 UTC+1, Ed Morley a écrit :
>
> (...)
>
> I'm happy to put together a PR to make the impact/complexity easier to
> judge, if that helps?
>
>
Yes, it always help to see the code.
> Before I do that I would just need to know whether the `username`,
> `password`
Hello,
I don't see much gain with that change, except for specific cases. This
would also bring a bunch of compatibility issues. I'd rather make the
change when it does bring something. I understand your consistency
argument, but we need to balance that with the work generated by the change
in
Le mercredi 2 mars 2016 02:42:05 UTC+1, Cristiano Coelho a écrit :
>
> Another approach for gender languages like spanish would be to use "el
> objeto %(obj)" rather than "el/la %(obj)".
>
That's exactly what we are doing for French.
Claude
--
You received this message because you are subscri
Le mardi 12 avril 2016 20:28:12 UTC+2, Wanjohi Kibui a écrit :
>
> Hello.Am working on a LIS in django and having difficulties on how to
> handle land services applications by clients and how they are handled in
> the system e.g. How its acted upon by many department each having a role to
> play
Le jeudi 21 avril 2016 21:23:16 UTC+2, Aymeric Augustin a écrit :
>
> For what it’s worth, I’m in favor of restoring the intended behavior of
> restricting usernames to ASCII on Python 3 and letting developers who want
> something more elaborate implement their own requirements.
>
I'm sorry to d
Le vendredi 22 avril 2016 14:25:59 UTC+2, Claude Paroz a écrit :
>
> I'll see if I can find the time to work on something acceptable, allowing
> people to choose either policy without too much hassle and backwards
> incompatibility. Of course, anyone else could try it, too.
&g
Hi Aymeric,
Le samedi 23 avril 2016 14:33:56 UTC+2, Aymeric Augustin a écrit :
>
> > https://github.com/django/django/pull/6494
>
> This patch looks pretty good. I have a few questions, not necessarily
> because I disagree with your proposal, but to make sure we have considered
> alternatives.
Le lundi 9 mai 2016 14:48:06 UTC+2, Tim Graham a écrit :
>
> Rather than change the behavior of Python 2 near its last supported
> version of Django, I would make the default validator ASCII on Python 2 and
> Unicode on Python 3.
>
I can buy this, providing we don't face migration issues.
Claud
Le mardi 10 mai 2016 00:28:57 UTC+2, Carl Meyer a écrit :
>
> I pushed an alternative approach in
>
> https://github.com/carljm/django/commit/7d734cfb9da2f64e4bf59c55167c70748b3bd092
>
> that removes the INSTALLED_APPS checking. Instead, it has the `render`
> method unconditionally fallback to
Le jeudi 12 mai 2016 18:45:15 UTC+2, Tim Graham a écrit :
>
> Just to be sure, do you mean django.db.migrations (referencing the
> appropriate validator in the migration file, I guess?) or some problem a
> project would face when migrating from Python 2 to 3?
>
Both things, hopefully not an issu
Le samedi 14 mai 2016 16:03:57 UTC+2, Tim Graham a écrit :
>
> (...)
>
> I guess it will affect every project that uses the admin. I can't think
> of a simple solution other than adding a system check upgrade warning to
> detect this situation ('django.contrib.admin' in INSTALLED_APPS but not
>
...always consider templates (not forms, sorry ) in django.forms ...
--
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 djang
Le mardi 17 mai 2016 08:03:52 UTC+2, Carl Meyer a écrit :
>
> On 05/16/2016 01:48 AM, Claude Paroz wrote:
>
> > I'm still answering with my naive hat: isn't it possible to simply
> > always consider forms in django.forms without requiring anything new in
> &
Hello Jani,
I'm not familiar with the Oracle backend, but you probably have to play
with the
OracleSpatialAdapter / WKTAdapter stuff to achieve what you need. Good luck!
Claude
Le mardi 17 mai 2016 14:53:28 UTC+2, Jani Tiainen a écrit :
>
> I'm toying around Oracle and latest cx_Oracle feature
The design and the patch look good to me. Thanks!
Claude
Le jeudi 19 mai 2016 05:01:37 UTC+2, Jon Dufresne a écrit :
>
> Hi,
>
> Occasionally I'll need to define a CharField on a model that is unique but
> also allow blank values. At the database level, this is easily handled by
> storing NULL
Le vendredi 20 mai 2016 02:44:41 UTC+2, Josh Smeaton a écrit :
>
> I understand the reasoning for "use the cache", but not every site has
> caching enabled, especially lots of smaller sites.
>
That's not true. When not specified, the cache backend default to the local
memory cache:
https://docs
Hi,
I have the general feeling that too few people are testing the new Django
major releases before the .0 release. The result being that many
regressions are often reported after the release, while those could have
been detected at alpha/beta/rc stages.
I found myself in the situation where I
Just a note that I open a discussion on making GDAL a hard requirement for
contrib.gis, on the GeoDjango mailing list:
https://groups.google.com/forum/#!topic/geodjango/gD0-1SMOBqU
Feel free to participate in that thread if you have something to say.
Claude
--
You received this message because
Le vendredi 17 juin 2016 16:52:50 UTC+2, Tim Graham a écrit :
>
> There are a few small issues to finish up, but if all goes well, the beta
> release will happen sometime tomorrow (at least 24 hours from now).
>
I'm a bit worried about https://code.djangoproject.com/ticket/26719 which
could have
Le vendredi 22 juillet 2016 23:30:58 UTC+2, Jon Dufresne a écrit :
>
> Hi,
>
> I would like to propose that Django renders the "checked" attribute of
> checkbox and radio inputs using the HTML5 boolean style attributes.
>
(...)
I'm definitely +1 with this change.
Hopefully, 1.11 should come with
Hi,
The ticket #25594 [1] is about the issue of adding custom validators to
model and form fields.
I made a code suggestion through a pull request [2], but I'd like to get
more opinions about the design and the proposal. Feel free to comment on
the ticket. Thanks!
Claude
[1] https://code.dja
Le vendredi 9 septembre 2016 07:31:42 UTC+2, Ivan Sagalaev a écrit :
> I think the best end result would be one where LOGGING simply defines the
>> full config and it is always applied (by Django) exactly once, and the
>> defaults we want are set as the global default for LOGGING, and just
>>
AFAIK Django receives the language tags from the browsers as IETF language
tags, and then convert them in locale names suitable for gettext.
https://en.wikipedia.org/wiki/IETF_language_tag
https://www.gnu.org/software/gettext/manual/gettext.html#Locale-Names
Hope this helps,
Claude
Le vendredi
I wouldn't spend too much energy about Python 2.7 stuff. Let the
workarounds in place, and just wait for Python 2 to die. I don't see the
point in forcing people of stable Debian-based distributions to install a
custom Python for 1.11.
--
You received this message because you are subscribed to
Le lundi 21 novembre 2016 23:56:56 UTC+1, Tim Graham a écrit :
>
> When reviewing the patch for the auth class-based view additions, I made
> the mistake of assuming that the existing tests would catch this type of
> obviously incorrect issue. Perhaps with the function-based views, the code
> wa
I would like to voice my support for Florian's arguments. It's not only
RedHat, Debian is also concerned. The current Jessie stable version which
will be supported probably until mid-2018 is Python 3.4, and the upcoming
stable version will most probably be Python 3.5. So a strong -1 for
droppin
Any idea why my message in this thread was deleted?
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-develop
Le mardi 17 janvier 2017 15:48:46 UTC+1, Tim Graham a écrit :
>
> I propose to tentatively target Python 3.5+ for Django 2.0 but not to
> remove the current workarounds for Python 3.4 at this time. Shortly before
> the alpha for Django 2.0, an interested person can look into how much work
> is r
Le lundi 23 janvier 2017 20:50:03 UTC+1, Tim Graham a écrit :
>
> (...) Do you think subclassing and extending the built-in backend is a
> common enough use case that it's worth formally deprecating the
> postgresql_psycopg2 module rather than simply removing it in Django 2.0?
>
I am generally s
Dear developers,
I'd like to suggest an addition to the Django Model definitions to ease the
implementation of translatable model fields. There are currently several
third-party applications for model translation, and even if I think we are
not ready yet to bless one of them to be included in c
Hi Raphael,
Le 14. 02. 17 à 14:53, Raphael Michel a écrit :
Hi Claude,
I spent some time looking at the implementations out there and in one
of my projects I'm running a custom one, that uses yet another approach
(that I plan to release as a library some day).
It is not only that we are not ye
Le 14. 02. 17 à 16:16, j...@yourlabs.org a écrit :
(...)
However, there's a third alternative to changing Meta that may be worth
suggesting: adding a new Field attribute ie. translatable=True, which
could be default for CharField and TextField perhaps. It might even turn
to be an advantage that n
Le 14. 02. 17 à 16:31, Patryk Zawadzki a écrit :
I think the proposed fields are mostly useful for translation utilities
that modify your schema on the fly. I consider these to be the least
clean solutions as they mean none of the translated fields can be marked
as required. For other solutions (
This might also be https://code.djangoproject.com/ticket/27086
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 dja
I also think that this should be handled at serialization level (form
fields and (de)serialization framework).
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 sto
Le mardi 16 mai 2017 23:52:31 UTC+2, Tom Forbes a écrit :
>
> Hello,
> Is anyone responsible for managing the transifex organisation? A colleague
> of mine applied to join the Django organisation to contribute greek
> translations for the admin, but his application is currently pending and
> has
As for me, I still think the current validator is valid for 99% of use
cases. And 99% of the time, an email address with dot-less domain is a user
input error.
So I would prefer fixing #25594 (validator propagation from db field to
form field), adding a "looser" validator in validators.py and b
I think we should first discuss if it makes sense to set a BigAutoField by
default for all tables. I'm not convinced of that yet. I looked at my
projects with this perspective and found for example a case where I have
many small lookup tables (containing between 2-20 entries) for which I know
I
Le samedi 10 juin 2017 11:40:42 UTC+2, Curtis Maloney a écrit :
>
> Right, hence my point of having a global setting to say "the default
> auto-field is ..."
>
> This would:
> a) ...
>
I see, but this conforms to the pattern "use the same id field type for all
models of my project". I'm not su
Le samedi 10 juin 2017 14:25:49 UTC+2, Curtis Maloney a écrit :
> On 10/06/17 22:21, Claude Paroz wrote:
> > Another idea would be to offer variants of models.Model which models
> > could inherit from, like models.BigIntModel or models.UUIDModel.
>
> Ah, well... now you&
101 - 167 of 167 matches
Mail list logo
