 | i18nSimplify the development of internationalized applications |
| Download | |
i18n Ranking & Summary
Advertisement
i18n Tags
i18n Description
i18n is a package that tries to simplify the workflow and development of internationalized applications. It is a thin wrapper around existing tools, in particular gettext and babel.Basic usage# demo.py#from i18n.translator import Translatorsupported_languages = # activate italian translationstr = Translator('/path/to/root', supported_languages, 'it_IT')print tr._('Hello world!')where /path/to/root/ is the root directory of your project. When instantiated, the Translator class automatically creates a directory called /path/to/root/languages where the translations are stored.Extracting messagesBefore doing the actual translation, you need to extract the messages from your source files, by invoking the extract command on the i18n module, which is a wrapper around pybabel extract and pybabel update: python -m i18n --root=/path/to/root --languages=it_IT,fr_FR,de_DE extractextract looks for all the messages wrapped inside calls to _(), gettext() or ngettext() and produces a file called languages/template.pot. This is a standard gettext po file` which contains all the messages found in the application.Moreover, extract() also creates a message catalog file for each of the supported languages as languages/$CODE/LC_MESSAGES/messages.po, where $CODE is one of the languages listed in supported_languages (it_IT, fr_FR and de_DE in the example above).The catalog files are now ready to be translated using one of the many existing tools, for example QT Linguist or Poedit. For the correct functioning of the application, the entire languages/ hierarchy needs to be preserved. We suggest to track the various messages.po files in Version Control System together with the other files belonging to the application.Updating messagesDuring the development of the application, you will surely add new messages to be translated. The extract command automatically handle this case: if it finds existing catalog files, their content (including the existing translations) is merged with the newly extracted messages.Compiling catalogsIt is necessary to compile the catalog files before using them with gettext. By default, our Translator object automatically compiles all the catalogs found in languages/, producing the corresponding .mo files. The compilation is done only when the catalog file has been modified. This means that in most cases you do not have to worry about the compilation of the catalogs.If you prefer to have more control on this step, you can pass autocompile=False to the constructor of Translator and compile them manually from the command line: python -m i18n --root=/path/to/root --languages=it_IT,fr_FR,de_DE compileStoring translations in a databaseFor some applications it is useful to let the user to define new translations and/or override the default ones. i18n supports this use case with the DBTranslator class, which is a subclass of Translator. When translating, DBTranslator first looks in the database: if the message is not found, it delegates to the standard gettext behavior.DBTranslator is based on sqlalchemy. Its constructor takes an additional engine parameter:from i18n.dbtranslator import DBTranslatorfrom sqlalchemy import create_engineengine = create_engine('sqlite:///db.sqlite')ROOT = '/path/to/root'LANGUAGES = DEST_LANGUAGE = 'it_IT'tr = DBTranslator(ROOT, LANGUAGES, DEST_LANGUAGE, engine=engine)print tr._("hello world")DBTranslator automatically creates the table translation_entries in the DB. Then, it is up to the application to provide an user interface to manipulate the table. For testing, you can use the add_translation() method to insert a new translation in the DB:tr.add_translation("it_IT", "hello world", "ciao mondo")print tr._("hello world") # prints "ciao mondo"How to use a global TranslatorBy design, i18n tries to completely avoid any global state. This means that you can instantiate as many Translator and DBTranslator as you want, each one referring to a different directory and/or database. This is especially useful for testing.However, in practice most projects want to use a global translator which knows about the messages of all the components in the project. The demo application shows a way to do it in the translate.py module:import pyfrom i18n.translator import Translator# set the root of the project to the directory containing this fileROOT = py.path.local(__file__).dirpath()LANGUAGES = tr = Translator(ROOT, LANGUAGES, 'it_IT')_ = tr._ngettext = tr.ngettextif __name__ == '__main__': tr.cmdline(sys.argv)This way, the rest of the application can simply import and use _() and ngettext() from translate.py. Or, at your preference, import directly the tr object and use tr._() and tr.ngettext() to translate messages.The last two lines of the code enables a convenient way to call extract and compile from the command line without having to manually specify the root dir and the supported languages. Just run: python translate.py extract # ...or compileProduct's homepage
i18n Related Software