Login

All snippets written in Python

2957 snippets

Snippet List

Django app/project/directory po messages collector and pofile bulder

Some times if third party application is not translated competelly, developer have to extract and save all of **i18n** strings of third party application to current project, somewhere in root project directory (and configure additional `LOCALE_DIRS` entry) or in any project's applications (usually named "main" or same as project). And after, create **po** file by makemessages, completely translate it and compile it to **mo** file. This script allows you to extract all messages (`msgid`) from all **po** files and save it in **python** file in **django** format — `_("Some i18n message")`, and also compile complex **po** file, contained all **msgids** with related **msgstrs** of third party application. Full example: You have third party app, which is translated to russian, but not completely and names **blog**. It contains two locale dirs and have, for example, the following structure: blog ..locale ....ru ......LC_MESSAGES ........django.mo ........django.po ..contrib ....comments ......locale ........ru ..........LC_MESSAGES ............django.mo ............django.po ......__init__.py ......models.py ..__init__.py ..models.py ..urls.py ..views.py Each po file may contains any set of strings, which may be duplicated accross the application and any other po files, anyway result **po** file will be contain only unique **msgids** and **msgstrs**. This application installed by pip into virtualenv lib directory and of cource you do not want change code here. To translate this application in your project it is possible to copy all (unstanslated) strings to you project as `ugettext` entries (usually `_("Some i18n string")`), make **po** file, translate it and compile **mo** file. So, after call this script (for example, let it be named `pomessages.py`), you will get two files, **django.py** which contains all i18n strings and **django.po** which contains all **msgids** (i18n strings) with related translations. `pomessages.py path/to/third-party-app/root locale [project-name:default is empty] [filename:default=django]` In this case: `pomessages.py path/to/blog ru blog django` After script will be finished, in blog directory will be added two files, **django.po** and **django.mo**. **django.py** content: ... # blog:admin (source:ru) directory translations # ---------------------------------------------- _("Category") # blog:models.py:10, blog:views.py:15 _("Article") # blog:models.py:20 # blog:category/admin (source:ru) directory translations # ------------------------------------------------------- _("Add Category") # blog:category/admin/templates/admin/create.html:10 _("Edit Category") # blog:category/admin/templates/admin/change.html:20 ... **django.mo** content: ... # msgid "" msgstr "" "Project-Id-Version: Blog\n" "POT-Creation-Date: 2016-02-08 12:00+0000\n" "PO-Revision-Date: 2016-02-08 18:00+0000\n" #: path/to/file.py:10 msgid "Category" msgstr "Категория" #: path/to/file.py:20 msgid "Article" msgstr "" ... After you just need to place **py** file anywhere in your project and place **po** file to the following locale directory (or merge with existing **po** file if it exists), run: `django-admin makemessages -lru` to fix **po file** (remake it), translate missing entries and run: `django-admin compilemessages`, reload project and you will have translated third party application.

  • django
  • i18n
  • python
  • pofile
Read More

Haystack whoosh backend with custom analyzer (allow using any lang, word processing, etc)

It is a haystack custom whoosh backend which provides analyzer customisation (required `get_analyzer` method definition). That means it is possible to define any complex analyzers (see [whoosh](https://bitbucket.org/mchaput/whoosh/wiki/Home) docs and source). Sample code shows how to use it, builtin `LanguageAnalyzer` instance configured for working with russian language used as custom analyzer. Base idea taken from this snippet: [https://djangosnippets.org/snippets/3025/](https://djangosnippets.org/snippets/3025/)

  • haystack
  • stemming
  • whoosh
  • analyzer
Read More

better localsettings import

Most people simply wrap "from localsettings import *" in a try/except ImportError block. That's what I've done for years, but recently came up with this better way. The problem this snippet solves is that if your localsettings.py itself causes an ImportError somehow, that error will be silently swallowed and your intended localsettings will be ignored. Instead, we use `imp` to first check if the module exists, then unconditionally try to import it.

  • development
  • staging
  • production
  • localsettings
Read More

Generic Outputting CSV with Django

Save the snippet as actions.py within your core app, and then add an action on any model you want in it's ModelAdmin definition. Example usage: `from actions import export_as_csv_action` `class YourModelAdmin(admin.ModelAdmin):` ` list_display = ('field', 'get_field2')` ` actions = [export_to_csv(filename='your-model')]` ` def get_field2(self, obj):` ` return obj.field2`

  • admin
  • unicode
  • export
  • csv
  • action
Read More

Filtering foreignkey fields in django admin

Sometimes you need to filter foreignkey choices in admin interface, to objects created by user or meeting some other condition. In django 1.0 there is no formfield_for_foreignkey method in ModelAdmin class so we have to make a workaround. Here is the solution I have found to be the easiest for me.

  • filter
  • admin
  • foreignkey
Read More

Add GET parameters from current request

The tag generates a parameter string in form '?param1=val1&param2=val2'. The parameter list is generated by taking all parameters from current request.GET and optionally overriding them by providing parameters to the tag. This is a cleaned up version of http://djangosnippets.org/snippets/2105/. It solves a couple of issues, namely: * parameters are optional * parameters can have values from request, e.g. request.GET.foo * native parsing methods are used for better compatibility and readability * shorter tag name Usage: place this code in your appdir/templatetags/add_get_parameter.py In template: {% load add_get_parameter %} <a href="{% add_get param1='const' param2=variable_in_context %}"> Link with modified params </a> It's required that you have 'django.core.context_processors.request' in TEMPLATE_CONTEXT_PROCESSORS

  • get
  • request
  • parameters
  • add
Read More

Validate request params without custom form

When work at site api for android client, I found use form to validate user input is too complex, so I write this. usage: @param('param_name', 'default_value', validate_func) def api_func(request): # access cleaned data. param_name = request.DATA['param_name'] JsonResponse is my class. replace with HttpResponse or whatever

  • request-validate
Read More

request_logger

Simple logger, stores all query parameter and post parameters for each query.

  • debugging
  • logger
Read More

pycallgraph

Simple debug middleware that uses [pycallgraph](http://pycallgraph.slowchop.com) to get a visual representation of the call graph, including number of calls and execution times. Usage: 1. Replace *myapp* in the snippet with the name of your application and or adjust include and exclude according to your needs 2. Add CallgraphMiddleware to your middlewares in settings.py 3. Append ?prof to any URL in your application to trigger the callgraph creation Each callgraph cerated will be named callgraph-*timestamp*.png. This is because multiple callgraphs will be created when a re-direction occurs for example.

  • middleware
  • profile
  • debug
Read More

Extended i18n base model

This snippet is an extension of [i18n base model for translatable content](http://djangosnippets.org/snippets/855/) so all the same usage applies. I have extended this module in several ways to make it more fully featured. * `I18NMixin` can be an additional (via multiple inheritance) or alternative superclass for your models juxtaposed with an `I18NModel`. * Adds a property `_` to access the appropriate I18NModel. `trans` aliases this (or rather vice versa) for template access. * In a call to `.filter` you can query on translated fields by wrapping those fields in a call to i18nQ. I like to import this as _ if I haven't already used that import. * A call to I18NFieldset will return an inline for use in the builtin admin app. I like to call this inline to the assignment to inlines. * If you need abstracted access to the I18N model from a model, I've added a property I18N referring to it. I've been using this with great convenience and stability.

  • models
  • i18n
  • metaclass
  • translated-content
Read More

LocaleMiddleware without browser language discovery

This snippet holds your Django project from automatically changing language of the page to the best fitting one by discovering the client browser language. I personally needed to show the page to the user for the first time in the default language (English), although there were some translations. User can still change the language (via session cookies). Insert this middleware BEFORE the Django's `django.middleware.locale.LocaleMiddleware` in settings.

  • middleware
  • i18n
  • locale
Read More