Re: admin/doc for templates ?
Hi Adrian, > > This sounds like a great addition to the automatic admin > documentation. Would you be willing to code up the patch? I don't know where to start for such changes. I would be happy if I could contribute such a patch. I think that you need to know a lot of internals ? Regards, Dirk -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Trac and Akismet rejected spam
I'd like to update the french translations urls in http://code.djangoproject.com/wiki/TranslateDocumentation with this new content : http://vrac.biologeek.com/askimet_error.txt and I get an Askimet rejected spam error. So, how can I do to update this page? Regards, David --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: django unicode-conversion, beginning
gabor wrote: > so what do you think about the following approach: > > try ascii-decoding > if fails, try utf8-decoding > if fails do iso-8859-1-decoding (this cannot fail). > > ? Dumb question maybe. How do you know this encoding ladder will work? > but imho this should happen only in "special" cases like > environ-variables.. for example in get/post params i would prefer to > raise an exception when the data cannot be en/de-coded using the > configured charset. You'd need to honor charset parameters sent out of Django apps and sent back by the client. A sensible default encoding to emit is UTF-8. cheers Bill --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: django unicode-conversion, beginning
Malcolm Tredinnick wrote: > On Wed, 2006-08-09 at 21:51 +0200, gabor wrote: > [...] >> phew... the immortal >> how-tolerant-we-should-be-when-doing-unicode-conversion problems :-) > > Agreed. This is much easier on my side of the fence (lobbing problems), > than your side (solving them). > [...] > All that being said, you could start off implementing your list and go > from there (although surely utf-8 decoding will also handle ASCII > strings, so you could skip the first step). These would be good rules to follow: - use unicode objects internally, weed out encoded bytestrings. - decode all loaded files and configuration into unicode; templates will be challenging. - initially at least, add assertions enforcing the use of unicode parameters (crash when you see a bytestring being passed into unicode aware code or across applications) - default encode to utf8 at server boundaries, modulo what Malcolm said about honoring charsets served out. - default de/encode in and out of utf8 for storage inside databases; it might be not possible and it might require a declaration in settings. - have the admin app strip out cp1252 to deal with cut and paste from windows; effbot has a dictionary that can be used for this. cheers Bill --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
ANN: Small security hole in compile-messages.py fixed
The Django team discovered and fixed a small security hole in the django/bin/compile-messages.py helper script, which is the script that compiles message files (.po files) into binary format (.mo files). The compile-messages.py script uses the name of the .po file to build arguments to a system command, and it didn't sufficiently validate the filename for potentially malicious content. Users who relied on the translation files provided with Django, or who wrote and compiled their own translations, were never at risk. Users who never ran the compile-messages.py script were never at risk. Only users who compiled third-party translations without examining the filenames first were potentially vulnerable. No exploit based on this vulnerability, proof-of-concept or otherwise, is known to have existed. Due to the nature of the vulnerability, we do not feel this merits a new release of Django. However, users who rely on third parties to supply translation files -- such as Django's own i18n maintainers -- are encouraged either to patch their code in one of these ways: * Upgrade to the latest Django trunk (the Django development version). * Simply overwrite your copy of django/bin/compile-messages.py with the new version found here: http://code.djangoproject.com/svn/django/trunk/django/bin/compile-messages.py This file has not changed in any backwards-incompatible way since before Django version 0.90, so it's safe to copy over, regardless of which Django version you're using. * We've applied the patches to Subversion "bug-fix" branches for both previous Django versions, 0.90 and 0.91. You can access those branches here: svn co http://code.djangoproject.com/svn/django/branches/0.90-bugfixes svn co http://code.djangoproject.com/svn/django/branches/0.91-bugfixes If none of those solutions is possible, we strongly encourage users to examine the names of translation files carefully before compiling them. Of course, the same standards should be applied when examining translation files from untrusted third parties as would be applied to any code received from an untrusted source. (All users are advised, as always, to keep in mind the risks of using *any* file from a third-party source, and to carefully examine any third-party code before executing it.) This security hole was fixed in changeset 3592. The patch is available here: http://code.djangoproject.com/changeset/3592 If you're interested in how we fixed the error, see the excellent document "String replacements in command lines": http://cyberelk.net/tim/articles/cmdline/ar01s02.html . Thanks to Rene Dudfield for reporting this. -The Django team (Cross-posted to django-announce, django-i18n, django-developers and django-users. We recently created the django-announce mailing list but it isn't yet well-known -- hence the wide net of mailing lists.) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
