Usage: {% load helper_tags %} {% get_available_languages as languages %} {% for lang_code, lang_name in languages %} <link rel="alternate" hreflang="{{ lang_code }}" href="{% change_lang lang_code %}"> {% endfor %}
- Choices are saved as the key integers. - Admin will show the correct translation in forms. - You can reuse the make_choices function for other choices fields. - Bad side: bin/make_messages.py won't get the choices values automatically, you have to add them in the .po's by hand.
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.
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.
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.
This is an example middleware that is highly inspired by how Symfony handles [i18n in URLs](http://www.symfony-project.com/book/trunk/13-I18n-and-L10n#Changing the Culture for a User). You basically set a (?P<dj_culture>[\w-]+) pattern in your URL and this middleware will determine the language to use for the i18n toolkit for Django. It also removes the dj_culture parameter after dealing with it, so that you don't have to change all the views you want this middleware to work with.
This is something we're using over at Curse to keep things clean and simple for our users. * We needed a url for any language code (which the domain provides) vs a cookie * We needed a to only store 2 letter codes in the db for each language (thus the key doesn't always match the code) This consists of two major modifications: * LANGUAGES in settings.py is a completely different format and would need changed based on your setup * the locale middleware has a couple absolute instances of where to point a user by default.
Together with my mentor, Dusty Phillips, I have developed a simple class that dynamically adds two fields to its subclasses. This is useful in cases when a single piece of content is divided into translatable and non-translatable fields, connected by a 1-to-many relationship. ## Update 2009/03/30 Since its inception, this snippet has grown into a significantly more powerful solution for translatable content (I use it myself with great joy :). The project is now hosted on github: [project page](http://github.com/foxbunny/django-i18n-model/tree/master) ## Update 2008/07/09 It is now possible to define `i18n_common_model` attribute in `class Meta` section. Here's an example: class Meta: i18n_common_model = "MyCommonModel" As you can see, it has to be a string, not the real class, and it is case-sensitive. ## Example class Article(models.Model): author = models.CharField(max_length = 40) class Admin: pass class ArticleI18N(I18NModel): title = models.CharField(max_length = 120) body = models.TextField() class Admin: pass # optionally, you can specify the base class # if it doesn't follow the naming convention: # # class Meta: # i18m_common_model = "Article" When the ArticleI18N class is created, it automatically gains two new fields. `lang` field is a CharField with choices limited to either `settings.LANGUAGES` or `django.conf.global_settings.LANGUAGES`. The other field is `i18n_common` field which is a ForeignKey to Article model. ## The conventions * call the translation model `SomeBaseModelI18N`, and the non-translation model SomeBaseModel (i.e., the translation model is called basename+"I18N") * the first convention can be overriden by specifying the base model name using the `i18n_common_model` attribute in `Meta` section of the `I18N` model * I18N model is a subclass of `I18NModel` class ## Original blog post [http://blog.papa-studio.com/2008/07/04/metaclasses-and-translations/](http://blog.papa-studio.com/2008/07/04/metaclasses-and-translations/)
This Snippet allows for your project's apps names to be displayed as you want in the Admin, including translations. The lists of apps and languages are created from your settings.py file. **How to use** 1st part: - Create a application called 'apps_verbose' in you project with the models.py and admin.py showed here - Create a folder inside it with named 'templatetags' with the verbose_tags.py file inside it. - Add this app to installed apps in your settings.py - If you change this app name, dont forget to correct the imports. 2nd part: - Create a folder named 'admin' in your templates folder and copy the following files form your /django/contrib/admin/templates/admin/ folder. - /app_index.html - /base.html - /change_form.html - /change_list.html - /delete_confirmation.html - /delete_selected_confirmation.html - /index.html - /object_history.html - Make the necessary changes in each file, like shown here. 3rd part: - Create translations in the Admin and enjoy.
This snippet display a human readable date diff. You give it the your date in parameter and the diff with datetime.datetime.now() is returned. The diff must be positive to be more accurate (future dates are not supported) Usage: {{ status.created_at|date_diff }} Will give something like: less than 1 minute ago 13 minutes ago 1 hour ago etc. Based on [Fuzzy Date Diff Template Filter](http://www.djangosnippets.org/snippets/1347/)
I18n Get all language with form. Tüm diller için otomatik form
Humanized and localized version of built-in *timesince* template filter. Based on [Joey Bratton's idea](http://www.joeyb.org/blog/2009/10/08/custom-django-template-filter-for-humanized-timesince).
This snippet is inspired by [dnordberg](http://djangosnippets.org/snippets/1048/) 's translation script which used google's translation script. But after google translation is no more free. I put together it to use microsoft translator's python wrapper by [openlab](https://github.com/openlabs/Microsoft-Translator-Python-API) usage ----- 1. get a bing appID from [here](https://ssl.bing.com/webmaster/developers/appids.aspx) and replace it on the top of script 2. sudo apt-get install translate-toolkit 3. sudo pip install microsofttranslator 4. sudo autotranslate.py [pofile] [sourcelangcode] [targetlangcode] Enjoy!!! **Prabhat Kumar Gupta** Python/Django Dev [http://www.prabhatgupta.com](http://www.prabhatgupta.com)
you have a multilingual site and need to change languages in admin. Previously this was easy in the site itself and more difficult in admin. Now it is dead easy. Set up your languages in settings.py. Make a directory called 'admin' in your templates directory, copy ~/django/contrib/admin/templates/base.html to that directory. Add the following code (below breadcrumbs is a good place) this will give you a switcher for all installed languages. You would need to refresh the browser on changing the language.
This is an extension of the DecimalField form field that uses my [Currency Object](http://www.djangosnippets.org/snippets/1525/) and [Currency Widget](http://www.djangosnippets.org/snippets/1526/). I placed my Currency object in the Django\\utils directory and the widget in Django\\froms\\widgets_special.py because I integrated a set of currency objects into the Admin app ( [here](http://www.djangosnippets.org/snippets/1529/) ) and it was just easier to have everything within Django. UPDATE 07-30-2009: Add the parse_string argument to properly test the string format as per the update to the [Currency Object](http://www.djangosnippets.org/snippets/1525/) UPDATE 09-15-2009: Properly handle None's in the clean method The rest of the series: [Currency Object](http://www.djangosnippets.org/snippets/1525/), [Currency Widget](http://www.djangosnippets.org/snippets/1526/), [Currency DB Field](http://www.djangosnippets.org/snippets/1528/), [Admin Integration](http://www.djangosnippets.org/snippets/1529/)