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 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 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 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)
Use in a with statement to set the translation to another locale for a block
>>> from django.utils.translation import ugettext
>>> ugettext('title')
u'title'
>>> with Translation('fr') as locale:
...: print locale.locale
...: print ugettext('title')
...:
...:
fr
titre
>>> ugettext('title')
u'title'
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 is a Model base class used to support internationalization (i18n) for your models.
This code extends the Django's Model class so you can use all available options from Model safely. Basicly, it uses introspection to create a sub-model to your model to hold translation.
**Features:**
1. Simplicity of use. You simply extend your model with this class and add all the fields that needs to be translated are placed under the `locale` sub-class;
2. The code uses the `django.utils.translation.get_language()` to select the current language;
3. You can use `python ./manage.py syncdb` command safely;
4. Force the user to enter a translation for each language even if the fields can be blank. This makes sure that all objects are returned safely.
**Ordering by locale fields:**
To sort on translated fields, use the form of "model_i18n__transfieldname" (see code for example).
**Limitation:**
Do not use localized fields in __unicode__, the admin will throw an exception when you'll add a new item and do "save and continue".
Just drop a comment if you need more information.
(last update: 06/15/2010)
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.
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.
The BooleanField and DecimalField `elif` blocks are only included in this snippet to give context in the admin_list.py. Insert the CurrencyField block into the file and the Currency fields will display properly in record lists. If you have all of the objects ( [Currency Object](http://www.djangosnippets.org/snippets/1525/), [Currency Widget](http://www.djangosnippets.org/snippets/1526/), [Currency Form Field](http://www.djangosnippets.org/snippets/1527/), and the [Currency DB Field](http://www.djangosnippets.org/snippets/1528/) ) then all you have to do is use the DB Field object and the Admin app will (should) work properly.
Please let me know if you have any problems.
This is an extension of the DecimalField database field that uses my [Currency Object](http://www.djangosnippets.org/snippets/1525/), [Currency Widget](http://www.djangosnippets.org/snippets/1526/), and [Currency Form Field](http://www.djangosnippets.org/snippets/1527/).
I placed my Currency object in the Django\\utils directory, the widget in Django\\froms\\widgets_special.py, and the form field in Django\\forms\\fields_special.py because I integrated this 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 08-18-2009: Added 'import decimal' and modified to_python slightly.
The rest of the series: [Currency Object](http://www.djangosnippets.org/snippets/1525/), [Currency Widget](http://www.djangosnippets.org/snippets/1526/), [Currency Form Field](http://www.djangosnippets.org/snippets/1527/), [Admin Integration](http://www.djangosnippets.org/snippets/1529/)
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/)