Blender i18n enhancements

This adds three new features:
* The ability to specify contexts in string property that are marked as PROP_PY_TRANSLATE, i.e. that are stored translated in RNA properties (used only by UI api funcs currently), using a simple 'context::message' format. Also done some cleanup in this area.

* A new bpy.app.i18n 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.

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, if enabled, 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 as well!

[ideasman42, 2013-01-14 17:35:28]

While I like that scripts could make translations Im hesitant to accept this
functionality as is, and think some areas should be done different.

- Im not convinced its a good idea to storing python data and using it for
translation lookups. It could be worth going to the extra bit of effort to have
scritps dump their own 'mo' files that blender can use.

- Not really liking storing the translation context in the text body
"SomeContext::Some Text"

- As stated in the review, Id like to be a general translation system any script
can register with, not addon specific.

https://codereview.appspot.com/7102054/diff/1/release/scripts/modules/addon_u...
File release/scripts/modules/addon_utils.py (right):

https://codereview.appspot.com/7102054/diff/1/release/scripts/modules/addon_u...
release/scripts/modules/addon_utils.py:297: # Try to register i18n messages
(translation for the addon) if any.
as stated in IRC, Id prefer not make addons translation aware, if the dev wants
to use translations they can do it explicitly.

https://codereview.appspot.com/7102054/diff/1/release/scripts/startup/bl_ui/p...
File release/scripts/startup/bl_ui/properties_material.py (right):

https://codereview.appspot.com/7102054/diff/1/release/scripts/startup/bl_ui/p...
release/scripts/startup/bl_ui/properties_material.py:308: col.prop(mat,
"use_specular_ramp", text="Color::Ramp")
Im not a fan of this method of passing on the encoding context.

Context should be stored in the property, in the case of labels that dont
reference a property could take an optional context argument.

# This prop can have its context defined in RNA
col.prop(mat, "use_specular_ramp", text="Ramp")

# This label could have a context passed
col.label(text="Ramp", context='COLOR')

https://codereview.appspot.com/7102054/diff/1/source/blender/makesdna/DNA_use...
File source/blender/makesdna/DNA_userdef_types.h (right):

https://codereview.appspot.com/7102054/diff/1/source/blender/makesdna/DNA_use...
source/blender/makesdna/DNA_userdef_types.h:610: USER_DOTRANSLATE_ADDON	= (1 <<
8),
*picky*, could be call this SCRIPT or PYTHON? -- translations shouldnt be addon
spesific.

https://codereview.appspot.com/7102054/diff/1/source/blender/python/intern/bp...
File source/blender/python/intern/bpy_app_i18n.c (right):

https://codereview.appspot.com/7102054/diff/1/source/blender/python/intern/bp...
source/blender/python/intern/bpy_app_i18n.c:75: const char
*BPY_app_i18n_addons_pgettext(const char *msgctxt, const char *msgid)
This runs on string drawing, and its locking the gil and doing dict lookups,
unicode conversions etc.

Did you consider having a utility function to compile the dict into a .mo file?
http://www.gnu.org/software/gettext/manual/html_node/MO-Files.html

Or, the PyDict could be convertex into a ghash or so. something for faster
lookups that avoids conversion overhead.

This can be left as a TODO I guess.

https://codereview.appspot.com/7102054/diff/1/source/blender/python/intern/bp...
source/blender/python/intern/bpy_app_i18n.c:99: PyObject *addon_dict;
prefer not be addon spesific, could name uuid_dict;  /* convention to use module
names */

https://codereview.appspot.com/7102054/diff/1/source/blender/python/intern/bp...
source/blender/python/intern/bpy_app_i18n.c:104: /* For each addon dict, we'll
search for full locale, then language+country, then language+variant,
could make this into a utility function of BLF ?

https://codereview.appspot.com/7102054/diff/1/source/blender/python/intern/bp...
source/blender/python/intern/bpy_app_i18n.c:202: static const char *kwlist[] =
{"addon_name", "i18n_dict", NULL};
prefer call it module_name.

[mont29, 2013-01-14 21:17:04]

Updated patch.

[mont29, 2013-01-14 21:21:20]

On 2013/01/14 21:17:04, mont29 wrote:
> Updated patch.

Addressed all issues from previous review (i.e. naming and using C ghash as
local i18n), except for the 'context in text parameter' stuff, for which I
really see no other way to handle it nicely and easily... :/

I honestly do not understand what's the problem in specifying a translation
context together with a string which is marked as "to be translated"... But
anyway, if this point is really considered problematic, it's easy to keep it as
is currently, for further investigation - it's not really tightly related to the
other things in the patch. ;)

[mont29, 2013-01-15 14:11:41]

Updated, removed the "context in text string" feature

[ideasman42, 2013-01-20 15:03:46]

LGTM - noted some minor issues.

https://codereview.appspot.com/7102054/diff/31/source/blender/python/intern/b...
File source/blender/python/intern/bpy_app.c (right):

https://codereview.appspot.com/7102054/diff/31/source/blender/python/intern/b...
source/blender/python/intern/bpy_app.c:94: {(char *)"i18n", (char *)"Application
and addons internationalization API"},
picky but perhaps 
'bpy.app.translations'
is nicer?

https://codereview.appspot.com/7102054/diff/31/source/blender/python/intern/b...
File source/blender/python/intern/bpy_app_i18n.c (right):

https://codereview.appspot.com/7102054/diff/31/source/blender/python/intern/b...
source/blender/python/intern/bpy_app_i18n.c:179: if (!PyArg_ParseTuple(pykey,
"ss", &msgctxt, &msgid)) {
In this case I'd suggest to manually get each string from the tuple ...
PyTuple_GETITEM, str = _PyUnicode_AsString() for each.

https://codereview.appspot.com/7102054/diff/31/source/blender/python/intern/b...
source/blender/python/intern/bpy_app_i18n.c:255: "   :return: None.\n"
you can just leave this out.

https://codereview.appspot.com/7102054/diff/31/source/blender/python/intern/b...
source/blender/python/intern/bpy_app_i18n.c:266: Py_RETURN_NONE;
Shouldn't this return NULL? (which would raise a python exception)

https://codereview.appspot.com/7102054/diff/31/source/blender/python/intern/b...
source/blender/python/intern/bpy_app_i18n.c:273: Py_RETURN_NONE;
same as above.

https://codereview.appspot.com/7102054/diff/31/source/blender/python/intern/b...
source/blender/python/intern/bpy_app_i18n.c:292: "   :return: None.\n"
you can just leave this out.

https://codereview.appspot.com/7102054/diff/31/source/blender/python/intern/b...
source/blender/python/intern/bpy_app_i18n.c:303: Py_RETURN_NONE;
again, return NULL for error cases

[brechtvl, 2013-01-20 15:26:31]

Added two comments about RNA part.

https://codereview.appspot.com/7102054/diff/31/source/blender/makesrna/intern...
File source/blender/makesrna/intern/rna_rna.c (right):

https://codereview.appspot.com/7102054/diff/31/source/blender/makesrna/intern...
source/blender/makesrna/intern/rna_rna.c:59: {PROP_PY_TRANSLATE, "TRANSLATE", 0,
"Translate",
I don't think this should be a subtype but a flag instead? That way it doesn't
get unnecessarily exposed to python, and it can work even if we ever add useful
string subtypes here.

https://codereview.appspot.com/7102054/diff/31/source/blender/makesrna/intern...
File source/blender/makesrna/intern/rna_userdef.c (right):

https://codereview.appspot.com/7102054/diff/31/source/blender/makesrna/intern...
source/blender/makesrna/intern/rna_userdef.c:3317: +	prop =
RNA_def_property(srna, "use_i18n_python", PROP_BOOLEAN, PROP_NONE);
I don't think this should be an option, just enable it always, don't think
addons should work different than builtin code here.

[mont29, 2013-01-20 17:34:49]

Applied suggested changes and committed. Thanks both of you for the reviews :)

https://codereview.appspot.com/7102054/diff/31/source/blender/makesrna/intern...
File source/blender/makesrna/intern/rna_rna.c (right):

https://codereview.appspot.com/7102054/diff/31/source/blender/makesrna/intern...
source/blender/makesrna/intern/rna_rna.c:59: {PROP_PY_TRANSLATE, "TRANSLATE", 0,
"Translate",
On 2013/01/20 15:26:31, brechtvl wrote:
> I don't think this should be a subtype but a flag instead? That way it doesn't
> get unnecessarily exposed to python, and it can work even if we ever add
useful
> string subtypes here.

Done.

https://codereview.appspot.com/7102054/diff/31/source/blender/makesrna/intern...
File source/blender/makesrna/intern/rna_userdef.c (right):

https://codereview.appspot.com/7102054/diff/31/source/blender/makesrna/intern...
source/blender/makesrna/intern/rna_userdef.c:3317: prop = RNA_def_property(srna,
"dpi", PROP_INT, PROP_NONE);
On 2013/01/20 15:26:31, brechtvl wrote:
> I don't think this should be an option, just enable it always, don't think
> addons should work different than builtin code here.

Done.

https://codereview.appspot.com/7102054/diff/31/source/blender/python/intern/b...
File source/blender/python/intern/bpy_app.c (right):

https://codereview.appspot.com/7102054/diff/31/source/blender/python/intern/b...
source/blender/python/intern/bpy_app.c:94: {(char *)"i18n", (char *)"Application
and addons internationalization API"},
On 2013/01/20 15:03:46, ideasman42 wrote:
> picky but perhaps 
> 'bpy.app.translations'
> is nicer?

Done.

https://codereview.appspot.com/7102054/diff/31/source/blender/python/intern/b...
File source/blender/python/intern/bpy_app_i18n.c (right):

https://codereview.appspot.com/7102054/diff/31/source/blender/python/intern/b...
source/blender/python/intern/bpy_app_i18n.c:179: if (!PyArg_ParseTuple(pykey,
"ss", &msgctxt, &msgid)) {
On 2013/01/20 15:03:46, ideasman42 wrote:
> In this case I'd suggest to manually get each string from the tuple ...
> PyTuple_GETITEM, str = _PyUnicode_AsString() for each.

Done.

https://codereview.appspot.com/7102054/diff/31/source/blender/python/intern/b...
source/blender/python/intern/bpy_app_i18n.c:255: "   :return: None.\n"
On 2013/01/20 15:03:46, ideasman42 wrote:
> you can just leave this out.

Done.

https://codereview.appspot.com/7102054/diff/31/source/blender/python/intern/b...
source/blender/python/intern/bpy_app_i18n.c:266: Py_RETURN_NONE;
On 2013/01/20 15:03:46, ideasman42 wrote:
> Shouldn't this return NULL? (which would raise a python exception)

Done.

https://codereview.appspot.com/7102054/diff/31/source/blender/python/intern/b...
source/blender/python/intern/bpy_app_i18n.c:273: Py_RETURN_NONE;
On 2013/01/20 15:03:46, ideasman42 wrote:
> same as above.

Done.

https://codereview.appspot.com/7102054/diff/31/source/blender/python/intern/b...
source/blender/python/intern/bpy_app_i18n.c:292: "   :return: None.\n"
On 2013/01/20 15:03:46, ideasman42 wrote:
> you can just leave this out.

Done.

https://codereview.appspot.com/7102054/diff/31/source/blender/python/intern/b...
source/blender/python/intern/bpy_app_i18n.c:303: Py_RETURN_NONE;
On 2013/01/20 15:03:46, ideasman42 wrote:
> again, return NULL for error cases

Done.