Commit Graph

7 Commits

Author SHA1 Message Date
4c0ebedc66 On second thought, exposes bpy.app.translations also when built without i18n support, this will avoid the need for py scripts to test for its presence everywhere! 2013-01-21 15:10:22 +00:00
e0063bd74f Print warnings when invalid py dict/key/value is found in translations data (do not error here, this is not critical and can be ignored/skiped, and it would break translations for other addons as well). 2013-01-21 12:01:47 +00:00
57221e13ee Expose locale_explode in bpy.app.translations, will be handy in i18n manipulation scripts/addons. 2013-01-21 10:57:24 +00:00
3aa499f3f7 I18n fix: "" context is not the same as NULL context!
This bug did not appear earlier because the "" default context was actually never used, always NULL context was passed instead. But bpy.app.translations uses "" as default context in its keys (simplifies the hash/comp functions of internal py messages cache)...

So now, Blender prefers NULL (None in python) as default context value, but understands also "" as such.
2013-01-21 10:52:34 +00:00
d05f46c12d minor changes to _build_translations_cache(), remove unneeded NULL checks and use slightly different funcs for getting strings. 2013-01-21 02:40:36 +00:00
38cee985bb code cleanup: style & warnings. 2013-01-21 02:30:40 +00:00
cef730d969 Python i18n API. Many thanks to Campbell and Brecht for the reviews and suggestions!
This commit adds:
* A new bpy.app.translations module giving some info about locales/translation stuff (current active locale, all locales currently known by blender, all translation contexts currently defined, etc.).

* The ability for addons to feature translations, using the (un)register functions of above module.

* Also cleans up "translate py string when storing into RNA prop" by removing "PROP_TRANSLATE" string's subtype, and adding a PROP_STRING_PY_TRANSLATE flag instead (this way it is no more exposed to python...).

Addon translations work with py dictionaries: each addon features a dict {lang: {(context, message): translation, ...}, ...}, which is registered when the addon is enabled (and unregistered when disabled). 

Then, when a key (context, message) is not found in regular mo catalog, a cache dict for current locale is built from all registered addon translations, and key is searched in it.

Note: currently addons writers have to do all the work by hand, will add something (probably extend "edit translation" addon) to automate messages extraction from addons soon(ish)! To get a look to expected behavior from addons, have a look at render_copy_settings/__init__.py and render_copy_settings/translations.py (rather stupid example currently, but...). Once we have a complete process, I'll also update relevant wiki pages.
2013-01-20 17:29:07 +00:00