Translation service

Translation tags which work with data stored in the database.

Why another translation service?

Current i18n implementation is great for static messages, but is unusable to translate messages from the database. I previously used separate tables for any translatable field in the model, but this is complicated and performance hungry method (not to mention that lots of messages gets duplicated).

With the coming of magic-removal branch and new features like event system I decided to go for the another approach - make something like gettext which will translate and use data from the database, and here are the results.

Features

• works with current django i18n implementation.
• no additional setup for models required.
• I18N(Char|Text)Field with additional magic ;) for register/delete and track changes to messages.
• translation is performed on the site (if logged in user has rights to do so, and translation mode is switched on). -- NOT DONE (YET)
• it will pass unknown messages to gettext machinery as a last resort.

Wish list

Feel free to add your own...

• Global switch to enable/disable translation mode (if user has right to translate messages).
• Interface like poEdit for message translation nicely incorporated with existing admin design.
• I still not found use-case for the pluralization - it will complicate database layout and for now I will not implement it.
• Better names for template tags, translate and blocktranslate can be easy mixed with original trans and blocktrans tags -- maybe db_trans and db_blocktrans?
• Translation dictionary.

Installation

See: AppInst for install instructions.

Then, in your templates use it like this: {% load nesh.translation %} {% translate object.field %}

Requirements

• Currently translation requires python 2.4 (easy fixable) (#6)
• It's recommended to install python Levenshtein module to compute similarity of two strings, if not, replacement using python difflib.SequenceMatcher will be used.

Current status

I'm added I18NCharField and I18NTextField which will take advantage of new magic removal event system to automatically add/change/delete message registry when field is changed. ''This is not required for translation usage, just as a helper''.

Also, first take of message registry is implemented.

Fields

Basicaly this fields are same as corresponding parent fields with added functionality.

This fields will not add anything to the admin interface or add additional models like my old I18N fields, main goal of this app is to stop explosion of additional tables needed for translation.

• attach to post_save and pre_delete events to update message registry
• save handler will register new message, or if message is changed it will register new message (leaving the old one in the database)
• delete handler will simply delete registry entry, it will not delete message from database

Tags

Both translate tags works like this:

• if current language is equal to default language, return message without translation
• translation is first searched in message database
  • if no translation is found pass message to gettext
  • if gettext has translation, store this translation in database
• return unchanged message

translate

Based on i18n trans tag.

Usage: {% translate object.field %}

blocktranslate

This will translate a block of text with parameters.

Usage: {% blocktranslate with object.field|filter as bar and object.field2|filter as boo %} This is {{ bar }} and {{ boo }}. {% endblocktranslate %}

Based on i18n blocktrans tag.