| 
									
										
											  
											
												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
										 |  |  | /*
 | 
					
						
							|  |  |  |  * This program is free software; you can redistribute it and/or | 
					
						
							|  |  |  |  * modify it under the terms of the GNU General Public License | 
					
						
							|  |  |  |  * as published by the Free Software Foundation; either version 2 | 
					
						
							|  |  |  |  * of the License, or (at your option) any later version. | 
					
						
							|  |  |  |  * | 
					
						
							|  |  |  |  * This program is distributed in the hope that it will be useful, | 
					
						
							|  |  |  |  * but WITHOUT ANY WARRANTY; without even the implied warranty of | 
					
						
							|  |  |  |  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the | 
					
						
							|  |  |  |  * GNU General Public License for more details. | 
					
						
							|  |  |  |  * | 
					
						
							|  |  |  |  * You should have received a copy of the GNU General Public License | 
					
						
							|  |  |  |  * along with this program; if not, write to the Free Software Foundation, | 
					
						
							|  |  |  |  * Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. | 
					
						
							|  |  |  |  */ | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2019-02-18 08:08:12 +11:00
										 |  |  | /** \file
 | 
					
						
							|  |  |  |  * \ingroup pythonintern | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |  * | 
					
						
							|  |  |  |  * This file defines a singleton py object accessed via 'bpy.app.translations', | 
					
						
							|  |  |  |  * which exposes various data and functions useful in i18n work. | 
					
						
							|  |  |  |  * Most notably, it allows to extend main translations with py dicts. | 
					
						
							|  |  |  |  */ | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | #include <Python.h>
 | 
					
						
							|  |  |  | /* XXX Why bloody hell isn't that included in Python.h???? */ | 
					
						
							|  |  |  | #include <structmember.h>
 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2013-03-04 19:27:51 +00:00
										 |  |  | #include "BLI_utildefines.h"
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 
 | 
					
						
							|  |  |  | #include "BPY_extern.h"
 | 
					
						
							|  |  |  | #include "bpy_app_translations.h"
 | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | #include "MEM_guardedalloc.h"
 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2015-08-16 17:32:01 +10:00
										 |  |  | #include "BLT_lang.h"
 | 
					
						
							| 
									
										
										
										
											2020-03-19 09:33:03 +01:00
										 |  |  | #include "BLT_translation.h"
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 
 | 
					
						
							|  |  |  | #include "RNA_types.h"
 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2015-01-06 16:42:22 +11:00
										 |  |  | #include "../generic/python_utildefines.h"
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2019-01-26 20:41:52 +11:00
										 |  |  | #ifdef WITH_INTERNATIONAL
 | 
					
						
							|  |  |  | #  include "BLI_ghash.h"
 | 
					
						
							| 
									
										
										
										
											2020-03-19 09:33:03 +01:00
										 |  |  | #  include "BLI_string.h"
 | 
					
						
							| 
									
										
										
										
											2019-01-26 20:41:52 +11:00
										 |  |  | #endif
 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2020-03-26 10:24:44 +11:00
										 |  |  | /* ------------------------------------------------------------------- */ | 
					
						
							|  |  |  | /** \name Local Struct to Store Translation
 | 
					
						
							|  |  |  |  * \{ */ | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2015-04-07 11:25:42 +10:00
										 |  |  | typedef struct { | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |   PyObject_HEAD | 
					
						
							| 
									
										
										
										
											2019-04-29 19:59:13 +10:00
										 |  |  |       /** The string used to separate context from actual message in PY_TRANSLATE RNA props. */ | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |       const char *context_separator; | 
					
						
							| 
									
										
										
										
											2019-04-29 19:59:13 +10:00
										 |  |  |   /** A "named tuple" (StructSequence actually...) containing all C-defined contexts. */ | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |   PyObject *contexts; | 
					
						
							| 
									
										
										
										
											2019-04-29 19:59:13 +10:00
										 |  |  |   /** A readonly mapping {C context id: python id}  (actually, a MappingProxy). */ | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |   PyObject *contexts_C_to_py; | 
					
						
							| 
									
										
										
										
											2019-04-29 19:59:13 +10:00
										 |  |  |   /**
 | 
					
						
							|  |  |  |    * A py dict containing all registered py dicts | 
					
						
							|  |  |  |    * (order is more or less random, first match wins!). | 
					
						
							|  |  |  |    */ | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |   PyObject *py_messages; | 
					
						
							|  |  |  | } BlenderAppTranslations; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | /* Our singleton instance pointer */ | 
					
						
							|  |  |  | static BlenderAppTranslations *_translations = NULL; | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2020-03-26 10:24:44 +11:00
										 |  |  | /** \} */ | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2013-01-21 15:10:22 +00:00
										 |  |  | #ifdef WITH_INTERNATIONAL
 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2020-03-26 10:24:44 +11:00
										 |  |  | /* ------------------------------------------------------------------- */ | 
					
						
							|  |  |  | /** \name Helpers for GHash
 | 
					
						
							|  |  |  |  * \{ */ | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | typedef struct GHashKey { | 
					
						
							|  |  |  |   const char *msgctxt; | 
					
						
							|  |  |  |   const char *msgid; | 
					
						
							|  |  |  | } GHashKey; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | static GHashKey *_ghashutil_keyalloc(const void *msgctxt, const void *msgid) | 
					
						
							|  |  |  | { | 
					
						
							| 
									
										
										
										
											2013-01-23 07:59:07 +00:00
										 |  |  |   GHashKey *key = MEM_mallocN(sizeof(GHashKey), "Py i18n GHashKey"); | 
					
						
							| 
									
										
										
										
											2015-08-16 17:32:01 +10:00
										 |  |  |   key->msgctxt = BLI_strdup(BLT_is_default_context(msgctxt) ? BLT_I18NCONTEXT_DEFAULT_BPYRNA : | 
					
						
							|  |  |  |                                                               msgctxt); | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |   key->msgid = BLI_strdup(msgid); | 
					
						
							|  |  |  |   return key; | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2020-02-20 15:38:58 +11:00
										 |  |  | static uint _ghashutil_keyhash(const void *ptr) | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | { | 
					
						
							|  |  |  |   const GHashKey *key = ptr; | 
					
						
							| 
									
										
										
										
											2020-08-20 16:10:13 +10:00
										 |  |  |   const uint hash = BLI_ghashutil_strhash(key->msgctxt); | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |   return hash ^ BLI_ghashutil_strhash(key->msgid); | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2014-09-25 17:00:07 +06:00
										 |  |  | static bool _ghashutil_keycmp(const void *a, const void *b) | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | { | 
					
						
							|  |  |  |   const GHashKey *A = a; | 
					
						
							|  |  |  |   const GHashKey *B = b; | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |   /* Note: comparing msgid first, most of the time it will be enough! */ | 
					
						
							| 
									
										
										
										
											2019-03-30 06:12:48 +11:00
										 |  |  |   if (BLI_ghashutil_strcmp(A->msgid, B->msgid) == false) { | 
					
						
							| 
									
										
										
										
											2014-09-25 14:29:23 +02:00
										 |  |  |     return BLI_ghashutil_strcmp(A->msgctxt, B->msgctxt); | 
					
						
							| 
									
										
										
										
											2019-03-30 06:12:48 +11:00
										 |  |  |   } | 
					
						
							| 
									
										
										
										
											2014-09-25 14:29:23 +02:00
										 |  |  |   return true; /* true means they are not equal! */ | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | static void _ghashutil_keyfree(void *ptr) | 
					
						
							|  |  |  | { | 
					
						
							|  |  |  |   const GHashKey *key = ptr; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |   /* We assume both msgctxt and msgid were BLI_strdup'ed! */ | 
					
						
							|  |  |  |   MEM_freeN((void *)key->msgctxt); | 
					
						
							|  |  |  |   MEM_freeN((void *)key->msgid); | 
					
						
							|  |  |  |   MEM_freeN((void *)key); | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2013-05-21 08:45:10 +00:00
										 |  |  | #  define _ghashutil_valfree MEM_freeN
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2020-03-26 10:24:44 +11:00
										 |  |  | /** \} */ | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | /* ------------------------------------------------------------------- */ | 
					
						
							|  |  |  | /** \name Python'S Messages Cache
 | 
					
						
							|  |  |  |  * \{ */ | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 
 | 
					
						
							|  |  |  | /* We cache all messages available for a given locale from all py dicts into a single ghash.
 | 
					
						
							| 
									
										
										
										
											2019-04-29 19:59:13 +10:00
										 |  |  |  * Changing of locale is not so common, while looking for a message translation is, | 
					
						
							|  |  |  |  * so let's try to optimize the later as much as we can! | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |  * Note changing of locale, as well as (un)registering a message dict, invalidate that cache. | 
					
						
							|  |  |  |  */ | 
					
						
							|  |  |  | static GHash *_translations_cache = NULL; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | static void _clear_translations_cache(void) | 
					
						
							|  |  |  | { | 
					
						
							|  |  |  |   if (_translations_cache) { | 
					
						
							|  |  |  |     BLI_ghash_free(_translations_cache, _ghashutil_keyfree, _ghashutil_valfree); | 
					
						
							|  |  |  |   } | 
					
						
							|  |  |  |   _translations_cache = NULL; | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | static void _build_translations_cache(PyObject *py_messages, const char *locale) | 
					
						
							|  |  |  | { | 
					
						
							| 
									
										
										
										
											2013-01-21 12:01:47 +00:00
										 |  |  |   PyObject *uuid, *uuid_dict; | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |   Py_ssize_t pos = 0; | 
					
						
							|  |  |  |   char *language = NULL, *language_country = NULL, *language_variant = NULL; | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |   /* For each py dict, we'll search for full locale, then language+country, then language+variant,
 | 
					
						
							|  |  |  |    * then only language keys... */ | 
					
						
							| 
									
										
										
										
											2015-08-16 17:32:01 +10:00
										 |  |  |   BLT_lang_locale_explode(locale, &language, NULL, NULL, &language_country, &language_variant); | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |   /* Clear the cached ghash if needed, and create a new one. */ | 
					
						
							|  |  |  |   _clear_translations_cache(); | 
					
						
							|  |  |  |   _translations_cache = BLI_ghash_new(_ghashutil_keyhash, _ghashutil_keycmp, __func__); | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |   /* Iterate over all py dicts. */ | 
					
						
							| 
									
										
										
										
											2013-01-21 12:01:47 +00:00
										 |  |  |   while (PyDict_Next(py_messages, &pos, &uuid, &uuid_dict)) { | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |     PyObject *lang_dict; | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | #  if 0
 | 
					
						
							|  |  |  |     PyObject_Print(uuid_dict, stdout, 0); | 
					
						
							|  |  |  |     printf("\n"); | 
					
						
							|  |  |  | #  endif
 | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2019-04-29 19:59:13 +10:00
										 |  |  |     /* Try to get first complete locale, then language+country,
 | 
					
						
							|  |  |  |      * then language+variant, then only language. */ | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |     lang_dict = PyDict_GetItemString(uuid_dict, locale); | 
					
						
							| 
									
										
										
										
											2013-01-21 12:01:47 +00:00
										 |  |  |     if (!lang_dict && language_country) { | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |       lang_dict = PyDict_GetItemString(uuid_dict, language_country); | 
					
						
							| 
									
										
										
										
											2013-01-21 12:01:47 +00:00
										 |  |  |       locale = language_country; | 
					
						
							|  |  |  |     } | 
					
						
							|  |  |  |     if (!lang_dict && language_variant) { | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |       lang_dict = PyDict_GetItemString(uuid_dict, language_variant); | 
					
						
							| 
									
										
										
										
											2013-01-21 12:01:47 +00:00
										 |  |  |       locale = language_variant; | 
					
						
							|  |  |  |     } | 
					
						
							|  |  |  |     if (!lang_dict && language) { | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |       lang_dict = PyDict_GetItemString(uuid_dict, language); | 
					
						
							| 
									
										
										
										
											2013-01-21 12:01:47 +00:00
										 |  |  |       locale = language; | 
					
						
							|  |  |  |     } | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2013-01-21 12:01:47 +00:00
										 |  |  |     if (lang_dict) { | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |       PyObject *pykey, *trans; | 
					
						
							|  |  |  |       Py_ssize_t ppos = 0; | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2013-01-21 12:01:47 +00:00
										 |  |  |       if (!PyDict_Check(lang_dict)) { | 
					
						
							|  |  |  |         printf("WARNING! In translations' dict of \""); | 
					
						
							|  |  |  |         PyObject_Print(uuid, stdout, Py_PRINT_RAW); | 
					
						
							|  |  |  |         printf("\":\n"); | 
					
						
							|  |  |  |         printf( | 
					
						
							|  |  |  |             "    Each language key must have a dictionary as value, \"%s\" is not valid, " | 
					
						
							|  |  |  |             "skipping: ", | 
					
						
							|  |  |  |             locale); | 
					
						
							|  |  |  |         PyObject_Print(lang_dict, stdout, Py_PRINT_RAW); | 
					
						
							|  |  |  |         printf("\n"); | 
					
						
							|  |  |  |         continue; | 
					
						
							|  |  |  |       } | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |       /* Iterate over all translations of the found language dict, and populate our ghash cache. */ | 
					
						
							| 
									
										
										
										
											2013-01-21 02:30:40 +00:00
										 |  |  |       while (PyDict_Next(lang_dict, &ppos, &pykey, &trans)) { | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |         const char *msgctxt = NULL, *msgid = NULL; | 
					
						
							| 
									
										
										
										
											2013-01-21 12:01:47 +00:00
										 |  |  |         bool invalid_key = false; | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2013-01-21 12:01:47 +00:00
										 |  |  |         if ((PyTuple_CheckExact(pykey) == false) || (PyTuple_GET_SIZE(pykey) != 2)) { | 
					
						
							|  |  |  |           invalid_key = true; | 
					
						
							| 
									
										
										
										
											2013-01-21 10:52:34 +00:00
										 |  |  |         } | 
					
						
							| 
									
										
										
										
											2013-01-21 12:01:47 +00:00
										 |  |  |         else { | 
					
						
							|  |  |  |           PyObject *tmp = PyTuple_GET_ITEM(pykey, 0); | 
					
						
							|  |  |  |           if (tmp == Py_None) { | 
					
						
							| 
									
										
										
										
											2015-08-16 17:32:01 +10:00
										 |  |  |             msgctxt = BLT_I18NCONTEXT_DEFAULT_BPYRNA; | 
					
						
							| 
									
										
										
										
											2013-01-21 12:01:47 +00:00
										 |  |  |           } | 
					
						
							|  |  |  |           else if (PyUnicode_Check(tmp)) { | 
					
						
							| 
									
										
										
										
											2021-02-13 22:57:01 +11:00
										 |  |  |             msgctxt = PyUnicode_AsUTF8(tmp); | 
					
						
							| 
									
										
										
										
											2013-01-21 12:01:47 +00:00
										 |  |  |           } | 
					
						
							|  |  |  |           else { | 
					
						
							|  |  |  |             invalid_key = true; | 
					
						
							|  |  |  |           } | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2013-01-21 12:01:47 +00:00
										 |  |  |           tmp = PyTuple_GET_ITEM(pykey, 1); | 
					
						
							|  |  |  |           if (PyUnicode_Check(tmp)) { | 
					
						
							| 
									
										
										
										
											2021-02-13 22:57:01 +11:00
										 |  |  |             msgid = PyUnicode_AsUTF8(tmp); | 
					
						
							| 
									
										
										
										
											2013-01-21 12:01:47 +00:00
										 |  |  |           } | 
					
						
							|  |  |  |           else { | 
					
						
							|  |  |  |             invalid_key = true; | 
					
						
							|  |  |  |           } | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |         } | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2013-01-21 12:01:47 +00:00
										 |  |  |         if (invalid_key) { | 
					
						
							|  |  |  |           printf("WARNING! In translations' dict of \""); | 
					
						
							|  |  |  |           PyObject_Print(uuid, stdout, Py_PRINT_RAW); | 
					
						
							|  |  |  |           printf("\", %s language:\n", locale); | 
					
						
							|  |  |  |           printf( | 
					
						
							|  |  |  |               "    Keys must be tuples of (msgctxt [string or None], msgid [string]), " | 
					
						
							|  |  |  |               "this one is not valid, skipping: "); | 
					
						
							|  |  |  |           PyObject_Print(pykey, stdout, Py_PRINT_RAW); | 
					
						
							|  |  |  |           printf("\n"); | 
					
						
							|  |  |  |           continue; | 
					
						
							|  |  |  |         } | 
					
						
							|  |  |  |         if (PyUnicode_Check(trans) == false) { | 
					
						
							|  |  |  |           printf("WARNING! In translations' dict of \""); | 
					
						
							|  |  |  |           PyObject_Print(uuid, stdout, Py_PRINT_RAW); | 
					
						
							|  |  |  |           printf("\":\n"); | 
					
						
							|  |  |  |           printf("    Values must be strings, this one is not valid, skipping: "); | 
					
						
							|  |  |  |           PyObject_Print(trans, stdout, Py_PRINT_RAW); | 
					
						
							|  |  |  |           printf("\n"); | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |           continue; | 
					
						
							|  |  |  |         } | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |         /* Do not overwrite existing keys! */ | 
					
						
							| 
									
										
										
										
											2016-03-01 11:40:23 +01:00
										 |  |  |         if (BPY_app_translations_py_pgettext(msgctxt, msgid) == msgid) { | 
					
						
							|  |  |  |           GHashKey *key = _ghashutil_keyalloc(msgctxt, msgid); | 
					
						
							| 
									
										
										
										
											2021-02-13 22:57:01 +11:00
										 |  |  |           BLI_ghash_insert(_translations_cache, key, BLI_strdup(PyUnicode_AsUTF8(trans))); | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |         } | 
					
						
							|  |  |  |       } | 
					
						
							|  |  |  |     } | 
					
						
							|  |  |  |   } | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |   /* Clean up! */ | 
					
						
							| 
									
										
										
										
											2014-12-27 17:24:39 +01:00
										 |  |  |   MEM_SAFE_FREE(language); | 
					
						
							|  |  |  |   MEM_SAFE_FREE(language_country); | 
					
						
							|  |  |  |   MEM_SAFE_FREE(language_variant); | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | const char *BPY_app_translations_py_pgettext(const char *msgctxt, const char *msgid) | 
					
						
							|  |  |  | { | 
					
						
							|  |  |  | #  define STATIC_LOCALE_SIZE 32 /* Should be more than enough! */
 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2016-03-01 11:40:23 +01:00
										 |  |  |   GHashKey key; | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |   static char locale[STATIC_LOCALE_SIZE] = ""; | 
					
						
							|  |  |  |   const char *tmp; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |   /* Just in case, should never happen! */ | 
					
						
							| 
									
										
										
										
											2019-03-30 06:12:48 +11:00
										 |  |  |   if (!_translations) { | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |     return msgid; | 
					
						
							| 
									
										
										
										
											2019-03-30 06:12:48 +11:00
										 |  |  |   } | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2015-08-16 17:32:01 +10:00
										 |  |  |   tmp = BLT_lang_get(); | 
					
						
							| 
									
										
										
										
											2015-01-26 16:03:11 +01:00
										 |  |  |   if (!STREQ(tmp, locale) || !_translations_cache) { | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |     PyGILState_STATE _py_state; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |     BLI_strncpy(locale, tmp, STATIC_LOCALE_SIZE); | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |     /* Locale changed or cache does not exist, refresh the whole cache! */ | 
					
						
							|  |  |  |     /* This func may be called from C (i.e. outside of python interpreter 'context'). */ | 
					
						
							|  |  |  |     _py_state = PyGILState_Ensure(); | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |     _build_translations_cache(_translations->py_messages, locale); | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |     PyGILState_Release(_py_state); | 
					
						
							|  |  |  |   } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |   /* And now, simply create the key (context, messageid) and find it in the cached dict! */ | 
					
						
							| 
									
										
										
										
											2016-03-01 11:40:23 +01:00
										 |  |  |   key.msgctxt = BLT_is_default_context(msgctxt) ? BLT_I18NCONTEXT_DEFAULT_BPYRNA : msgctxt; | 
					
						
							|  |  |  |   key.msgid = msgid; | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2016-03-01 11:40:23 +01:00
										 |  |  |   tmp = BLI_ghash_lookup(_translations_cache, &key); | 
					
						
							| 
									
										
										
										
											2013-01-23 07:59:07 +00:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2013-02-13 11:52:01 +00:00
										 |  |  |   return tmp ? tmp : msgid; | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 
 | 
					
						
							|  |  |  | #  undef STATIC_LOCALE_SIZE
 | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2013-01-21 15:10:22 +00:00
										 |  |  | #endif /* WITH_INTERNATIONAL */
 | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | PyDoc_STRVAR(app_translations_py_messages_register_doc, | 
					
						
							|  |  |  |              ".. method:: register(module_name, translations_dict)\n" | 
					
						
							|  |  |  |              "\n" | 
					
						
							|  |  |  |              "   Registers an addon's UI translations.\n" | 
					
						
							|  |  |  |              "\n" | 
					
						
							| 
									
										
										
										
											2013-05-14 15:33:59 +00:00
										 |  |  |              "   .. note::\n" | 
					
						
							| 
									
										
										
										
											2018-11-14 09:04:24 +11:00
										 |  |  |              "      Does nothing when Blender is built without internationalization support.\n" | 
					
						
							| 
									
										
										
										
											2013-01-21 15:10:22 +00:00
										 |  |  |              "\n" | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |              "   :arg module_name: The name identifying the addon.\n" | 
					
						
							|  |  |  |              "   :type module_name: string\n" | 
					
						
							|  |  |  |              "   :arg translations_dict: A dictionary built like that:\n" | 
					
						
							| 
									
										
										
										
											2018-11-14 09:04:24 +11:00
										 |  |  |              "      ``{locale: {msg_key: msg_translation, ...}, ...}``\n" | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |              "   :type translations_dict: dict\n" | 
					
						
							|  |  |  |              "\n"); | 
					
						
							|  |  |  | static PyObject *app_translations_py_messages_register(BlenderAppTranslations *self, | 
					
						
							|  |  |  |                                                        PyObject *args, | 
					
						
							|  |  |  |                                                        PyObject *kw) | 
					
						
							|  |  |  | { | 
					
						
							| 
									
										
										
										
											2013-01-21 15:10:22 +00:00
										 |  |  | #ifdef WITH_INTERNATIONAL
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |   static const char *kwlist[] = {"module_name", "translations_dict", NULL}; | 
					
						
							|  |  |  |   PyObject *module_name, *uuid_dict; | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |   if (!PyArg_ParseTupleAndKeywords(args, | 
					
						
							|  |  |  |                                    kw, | 
					
						
							|  |  |  |                                    "O!O!:bpy.app.translations.register", | 
					
						
							|  |  |  |                                    (char **)kwlist, | 
					
						
							|  |  |  |                                    &PyUnicode_Type, | 
					
						
							|  |  |  |                                    &module_name, | 
					
						
							|  |  |  |                                    &PyDict_Type, | 
					
						
							|  |  |  |                                    &uuid_dict)) { | 
					
						
							|  |  |  |     return NULL; | 
					
						
							|  |  |  |   } | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |   if (PyDict_Contains(self->py_messages, module_name)) { | 
					
						
							|  |  |  |     PyErr_Format( | 
					
						
							|  |  |  |         PyExc_ValueError, | 
					
						
							|  |  |  |         "bpy.app.translations.register: translations message cache already contains some data for " | 
					
						
							| 
									
										
										
										
											2013-01-21 12:01:47 +00:00
										 |  |  |         "addon '%s'", | 
					
						
							| 
									
										
										
										
											2021-02-13 22:57:01 +11:00
										 |  |  |         (const char *)PyUnicode_AsUTF8(module_name)); | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |     return NULL; | 
					
						
							|  |  |  |   } | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |   PyDict_SetItem(self->py_messages, module_name, uuid_dict); | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |   /* Clear cached messages dict! */ | 
					
						
							|  |  |  |   _clear_translations_cache(); | 
					
						
							| 
									
										
										
										
											2013-01-21 15:10:22 +00:00
										 |  |  | #else
 | 
					
						
							|  |  |  |   (void)self; | 
					
						
							|  |  |  |   (void)args; | 
					
						
							|  |  |  |   (void)kw; | 
					
						
							|  |  |  | #endif
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 
 | 
					
						
							|  |  |  |   /* And we are done! */ | 
					
						
							|  |  |  |   Py_RETURN_NONE; | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | PyDoc_STRVAR(app_translations_py_messages_unregister_doc, | 
					
						
							|  |  |  |              ".. method:: unregister(module_name)\n" | 
					
						
							|  |  |  |              "\n" | 
					
						
							|  |  |  |              "   Unregisters an addon's UI translations.\n" | 
					
						
							|  |  |  |              "\n" | 
					
						
							| 
									
										
										
										
											2013-05-14 15:33:59 +00:00
										 |  |  |              "   .. note::\n" | 
					
						
							| 
									
										
										
										
											2018-11-14 09:04:24 +11:00
										 |  |  |              "      Does nothing when Blender is built without internationalization support.\n" | 
					
						
							| 
									
										
										
										
											2013-01-21 15:10:22 +00:00
										 |  |  |              "\n" | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |              "   :arg module_name: The name identifying the addon.\n" | 
					
						
							|  |  |  |              "   :type module_name: string\n" | 
					
						
							|  |  |  |              "\n"); | 
					
						
							|  |  |  | static PyObject *app_translations_py_messages_unregister(BlenderAppTranslations *self, | 
					
						
							|  |  |  |                                                          PyObject *args, | 
					
						
							|  |  |  |                                                          PyObject *kw) | 
					
						
							|  |  |  | { | 
					
						
							| 
									
										
										
										
											2013-01-21 15:10:22 +00:00
										 |  |  | #ifdef WITH_INTERNATIONAL
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |   static const char *kwlist[] = {"module_name", NULL}; | 
					
						
							|  |  |  |   PyObject *module_name; | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |   if (!PyArg_ParseTupleAndKeywords(args, | 
					
						
							|  |  |  |                                    kw, | 
					
						
							|  |  |  |                                    "O!:bpy.app.translations.unregister", | 
					
						
							|  |  |  |                                    (char **)kwlist, | 
					
						
							|  |  |  |                                    &PyUnicode_Type, | 
					
						
							|  |  |  |                                    &module_name)) { | 
					
						
							|  |  |  |     return NULL; | 
					
						
							|  |  |  |   } | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |   if (PyDict_Contains(self->py_messages, module_name)) { | 
					
						
							|  |  |  |     PyDict_DelItem(self->py_messages, module_name); | 
					
						
							|  |  |  |     /* Clear cached messages ghash! */ | 
					
						
							|  |  |  |     _clear_translations_cache(); | 
					
						
							|  |  |  |   } | 
					
						
							| 
									
										
										
										
											2013-01-21 15:10:22 +00:00
										 |  |  | #else
 | 
					
						
							|  |  |  |   (void)self; | 
					
						
							|  |  |  |   (void)args; | 
					
						
							|  |  |  |   (void)kw; | 
					
						
							|  |  |  | #endif
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 
 | 
					
						
							|  |  |  |   /* And we are done! */ | 
					
						
							|  |  |  |   Py_RETURN_NONE; | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2020-03-26 10:24:44 +11:00
										 |  |  | /** \} */ | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | /* ------------------------------------------------------------------- */ | 
					
						
							|  |  |  | /** \name C-defined Contexts
 | 
					
						
							|  |  |  |  * \{ */ | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2013-01-21 15:10:22 +00:00
										 |  |  | /* This is always available (even when WITH_INTERNATIONAL is not defined). */ | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 
 | 
					
						
							|  |  |  | static PyTypeObject BlenderAppTranslationsContextsType; | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2015-08-16 17:32:01 +10:00
										 |  |  | static BLT_i18n_contexts_descriptor _contexts[] = BLT_I18NCONTEXTS_DESC; | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 
 | 
					
						
							|  |  |  | /* These fields are just empty placeholders, actual values get set in app_translations_struct().
 | 
					
						
							| 
									
										
										
										
											2019-04-29 19:59:13 +10:00
										 |  |  |  * This allows us to avoid many handwriting, and above all, | 
					
						
							|  |  |  |  * to keep all context definition stuff in BLT_translation.h! */ | 
					
						
							| 
									
										
										
										
											2014-06-17 02:47:57 +10:00
										 |  |  | static PyStructSequence_Field app_translations_contexts_fields[ARRAY_SIZE(_contexts)] = {{NULL}}; | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 
 | 
					
						
							|  |  |  | static PyStructSequence_Desc app_translations_contexts_desc = { | 
					
						
							| 
									
										
										
										
											2020-11-06 10:29:00 +11:00
										 |  |  |     "bpy.app.translations.contexts",                                 /* name */ | 
					
						
							| 
									
										
										
										
											2020-11-05 07:52:58 -08:00
										 |  |  |     "This named tuple contains all predefined translation contexts", /* doc */ | 
					
						
							| 
									
										
										
										
											2020-11-06 10:29:00 +11:00
										 |  |  |     app_translations_contexts_fields,                                /* fields */ | 
					
						
							| 
									
										
										
										
											2019-02-03 14:01:45 +11:00
										 |  |  |     ARRAY_SIZE(app_translations_contexts_fields) - 1, | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | }; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | static PyObject *app_translations_contexts_make(void) | 
					
						
							|  |  |  | { | 
					
						
							|  |  |  |   PyObject *translations_contexts; | 
					
						
							| 
									
										
										
										
											2015-08-16 17:32:01 +10:00
										 |  |  |   BLT_i18n_contexts_descriptor *ctxt; | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |   int pos = 0; | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |   translations_contexts = PyStructSequence_New(&BlenderAppTranslationsContextsType); | 
					
						
							|  |  |  |   if (translations_contexts == NULL) { | 
					
						
							|  |  |  |     return NULL; | 
					
						
							|  |  |  |   } | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | #define SetObjString(item) \
 | 
					
						
							|  |  |  |   PyStructSequence_SET_ITEM(translations_contexts, pos++, PyUnicode_FromString((item))) | 
					
						
							| 
									
										
										
										
											2015-01-06 16:42:22 +11:00
										 |  |  | #define SetObjNone() \
 | 
					
						
							|  |  |  |   PyStructSequence_SET_ITEM(translations_contexts, pos++, Py_INCREF_RET(Py_None)) | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |   for (ctxt = _contexts; ctxt->c_id; ctxt++) { | 
					
						
							| 
									
										
										
										
											2013-01-21 10:52:34 +00:00
										 |  |  |     if (ctxt->value) { | 
					
						
							|  |  |  |       SetObjString(ctxt->value); | 
					
						
							|  |  |  |     } | 
					
						
							|  |  |  |     else { | 
					
						
							|  |  |  |       SetObjNone(); | 
					
						
							|  |  |  |     } | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |   } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | #undef SetObjString
 | 
					
						
							| 
									
										
										
										
											2013-01-21 10:52:34 +00:00
										 |  |  | #undef SetObjNone
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 
 | 
					
						
							|  |  |  |   return translations_contexts; | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2020-03-26 10:24:44 +11:00
										 |  |  | /** \} */ | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | /* ------------------------------------------------------------------- */ | 
					
						
							|  |  |  | /** \name Main #BlenderAppTranslations #PyObject Definition
 | 
					
						
							|  |  |  |  * \{ */ | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 
 | 
					
						
							|  |  |  | PyDoc_STRVAR(app_translations_contexts_doc, | 
					
						
							| 
									
										
										
										
											2020-11-05 07:52:58 -08:00
										 |  |  |              "A named tuple containing all predefined translation contexts.\n" | 
					
						
							| 
									
										
										
										
											2015-03-02 16:43:14 +11:00
										 |  |  |              "\n" | 
					
						
							|  |  |  |              ".. warning::\n" | 
					
						
							| 
									
										
										
										
											2018-11-14 09:04:24 +11:00
										 |  |  |              "   Never use a (new) context starting with \"" BLT_I18NCONTEXT_DEFAULT_BPYRNA | 
					
						
							|  |  |  |              "\", it would be internally\n" | 
					
						
							|  |  |  |              "   assimilated as the default one!\n"); | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 
 | 
					
						
							|  |  |  | PyDoc_STRVAR(app_translations_contexts_C_to_py_doc, | 
					
						
							|  |  |  |              "A readonly dict mapping contexts' C-identifiers to their py-identifiers."); | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2013-03-22 05:34:10 +00:00
										 |  |  | static PyMemberDef app_translations_members[] = { | 
					
						
							| 
									
										
										
										
											2019-12-20 10:42:57 +11:00
										 |  |  |     {"contexts", | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |      T_OBJECT_EX, | 
					
						
							|  |  |  |      offsetof(BlenderAppTranslations, contexts), | 
					
						
							|  |  |  |      READONLY, | 
					
						
							|  |  |  |      app_translations_contexts_doc}, | 
					
						
							| 
									
										
										
										
											2019-12-20 10:42:57 +11:00
										 |  |  |     {"contexts_C_to_py", | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |      T_OBJECT_EX, | 
					
						
							|  |  |  |      offsetof(BlenderAppTranslations, contexts_C_to_py), | 
					
						
							|  |  |  |      READONLY, | 
					
						
							|  |  |  |      app_translations_contexts_C_to_py_doc}, | 
					
						
							| 
									
										
										
										
											2019-02-03 14:01:45 +11:00
										 |  |  |     {NULL}, | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | }; | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2013-01-21 15:10:22 +00:00
										 |  |  | PyDoc_STRVAR(app_translations_locale_doc, | 
					
						
							| 
									
										
										
										
											2015-03-02 16:43:14 +11:00
										 |  |  |              "The actual locale currently in use (will always return a void string when Blender " | 
					
						
							|  |  |  |              "is built without " | 
					
						
							|  |  |  |              "internationalization support)."); | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | static PyObject *app_translations_locale_get(PyObject *UNUSED(self), void *UNUSED(userdata)) | 
					
						
							|  |  |  | { | 
					
						
							| 
									
										
										
										
											2015-08-16 17:32:01 +10:00
										 |  |  |   return PyUnicode_FromString(BLT_lang_get()); | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | /* Note: defining as getter, as (even if quite unlikely), this *may* change during runtime... */ | 
					
						
							|  |  |  | PyDoc_STRVAR(app_translations_locales_doc, | 
					
						
							|  |  |  |              "All locales currently known by Blender (i.e. available as translations)."); | 
					
						
							|  |  |  | static PyObject *app_translations_locales_get(PyObject *UNUSED(self), void *UNUSED(userdata)) | 
					
						
							|  |  |  | { | 
					
						
							|  |  |  |   PyObject *ret; | 
					
						
							| 
									
										
										
										
											2015-08-16 17:32:01 +10:00
										 |  |  |   EnumPropertyItem *it, *items = BLT_lang_RNA_enum_properties(); | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |   int num_locales = 0, pos = 0; | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2013-01-21 15:10:22 +00:00
										 |  |  |   if (items) { | 
					
						
							|  |  |  |     /* This is not elegant, but simple! */ | 
					
						
							|  |  |  |     for (it = items; it->identifier; it++) { | 
					
						
							| 
									
										
										
										
											2019-03-30 06:12:48 +11:00
										 |  |  |       if (it->value) { | 
					
						
							| 
									
										
										
										
											2013-01-21 15:10:22 +00:00
										 |  |  |         num_locales++; | 
					
						
							| 
									
										
										
										
											2019-03-30 06:12:48 +11:00
										 |  |  |       } | 
					
						
							| 
									
										
										
										
											2013-01-21 15:10:22 +00:00
										 |  |  |     } | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |   } | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |   ret = PyTuple_New(num_locales); | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2013-01-21 15:10:22 +00:00
										 |  |  |   if (items) { | 
					
						
							|  |  |  |     for (it = items; it->identifier; it++) { | 
					
						
							| 
									
										
										
										
											2019-03-30 06:12:48 +11:00
										 |  |  |       if (it->value) { | 
					
						
							| 
									
										
										
										
											2013-01-21 15:10:22 +00:00
										 |  |  |         PyTuple_SET_ITEM(ret, pos++, PyUnicode_FromString(it->description)); | 
					
						
							| 
									
										
										
										
											2019-03-30 06:12:48 +11:00
										 |  |  |       } | 
					
						
							| 
									
										
										
										
											2013-01-21 15:10:22 +00:00
										 |  |  |     } | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |   } | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |   return ret; | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2013-03-22 05:34:10 +00:00
										 |  |  | static PyGetSetDef app_translations_getseters[] = { | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |     /* {name, getter, setter, doc, userdata} */ | 
					
						
							| 
									
										
										
										
											2019-12-20 10:42:57 +11:00
										 |  |  |     {"locale", (getter)app_translations_locale_get, NULL, app_translations_locale_doc, NULL}, | 
					
						
							|  |  |  |     {"locales", (getter)app_translations_locales_get, NULL, app_translations_locales_doc, NULL}, | 
					
						
							| 
									
										
										
										
											2019-02-03 14:01:45 +11:00
										 |  |  |     {NULL}, | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | }; | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2013-02-10 10:29:38 +00:00
										 |  |  | /* pgettext helper. */ | 
					
						
							|  |  |  | static PyObject *_py_pgettext(PyObject *args, | 
					
						
							|  |  |  |                               PyObject *kw, | 
					
						
							|  |  |  |                               const char *(*_pgettext)(const char *, const char *)) | 
					
						
							|  |  |  | { | 
					
						
							|  |  |  |   static const char *kwlist[] = {"msgid", "msgctxt", NULL}; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | #ifdef WITH_INTERNATIONAL
 | 
					
						
							|  |  |  |   char *msgid, *msgctxt = NULL; | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2013-02-14 23:49:30 +00:00
										 |  |  |   if (!PyArg_ParseTupleAndKeywords( | 
					
						
							|  |  |  |           args, kw, "s|z:bpy.app.translations.pgettext", (char **)kwlist, &msgid, &msgctxt)) { | 
					
						
							| 
									
										
										
										
											2013-02-10 10:29:38 +00:00
										 |  |  |     return NULL; | 
					
						
							|  |  |  |   } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2015-08-16 17:32:01 +10:00
										 |  |  |   return PyUnicode_FromString((*_pgettext)(msgctxt ? msgctxt : BLT_I18NCONTEXT_DEFAULT, msgid)); | 
					
						
							| 
									
										
										
										
											2013-02-10 10:29:38 +00:00
										 |  |  | #else
 | 
					
						
							|  |  |  |   PyObject *msgid, *msgctxt; | 
					
						
							|  |  |  |   (void)_pgettext; | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2013-02-14 23:49:30 +00:00
										 |  |  |   if (!PyArg_ParseTupleAndKeywords( | 
					
						
							|  |  |  |           args, kw, "O|O:bpy.app.translations.pgettext", (char **)kwlist, &msgid, &msgctxt)) { | 
					
						
							| 
									
										
										
										
											2013-02-10 10:29:38 +00:00
										 |  |  |     return NULL; | 
					
						
							|  |  |  |   } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2015-01-06 16:42:22 +11:00
										 |  |  |   return Py_INCREF_RET(msgid); | 
					
						
							| 
									
										
										
										
											2013-02-10 10:29:38 +00:00
										 |  |  | #endif
 | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | PyDoc_STRVAR( | 
					
						
							|  |  |  |     app_translations_pgettext_doc, | 
					
						
							| 
									
										
										
										
											2020-07-29 10:01:42 +10:00
										 |  |  |     ".. method:: pgettext(msgid, msgctxt=None)\n" | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |     "\n" | 
					
						
							|  |  |  |     "   Try to translate the given msgid (with optional msgctxt).\n" | 
					
						
							| 
									
										
										
										
											2013-05-14 15:33:59 +00:00
										 |  |  |     "\n" | 
					
						
							|  |  |  |     "   .. note::\n" | 
					
						
							| 
									
										
										
										
											2018-11-14 09:04:24 +11:00
										 |  |  |     "      The ``(msgid, msgctxt)`` parameters order has been switched compared to gettext " | 
					
						
							|  |  |  |     "function, to allow\n" | 
					
						
							|  |  |  |     "      single-parameter calls (context then defaults to BLT_I18NCONTEXT_DEFAULT).\n" | 
					
						
							| 
									
										
										
										
											2013-05-14 15:33:59 +00:00
										 |  |  |     "\n" | 
					
						
							|  |  |  |     "   .. note::\n" | 
					
						
							| 
									
										
										
										
											2018-11-14 09:04:24 +11:00
										 |  |  |     "      You should really rarely need to use this function in regular addon code, as all " | 
					
						
							|  |  |  |     "translation should be\n" | 
					
						
							|  |  |  |     "      handled by Blender internal code. The only exception are string containing formatting " | 
					
						
							|  |  |  |     "(like \"File: %r\"),\n" | 
					
						
							|  |  |  |     "      but you should rather use :func:`pgettext_iface`/:func:`pgettext_tip` in those cases!\n" | 
					
						
							| 
									
										
										
										
											2013-05-14 15:33:59 +00:00
										 |  |  |     "\n" | 
					
						
							|  |  |  |     "   .. note::\n" | 
					
						
							| 
									
										
										
										
											2018-11-14 09:04:24 +11:00
										 |  |  |     "      Does nothing when Blender is built without internationalization support (hence always " | 
					
						
							|  |  |  |     "returns ``msgid``).\n" | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |     "\n" | 
					
						
							|  |  |  |     "   :arg msgid: The string to translate.\n" | 
					
						
							|  |  |  |     "   :type msgid: string\n" | 
					
						
							| 
									
										
										
										
											2015-08-16 17:32:01 +10:00
										 |  |  |     "   :arg msgctxt: The translation context (defaults to BLT_I18NCONTEXT_DEFAULT).\n" | 
					
						
							| 
									
										
										
										
											2013-01-21 10:52:34 +00:00
										 |  |  |     "   :type msgctxt: string or None\n" | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |     "   :return: The translated string (or msgid if no translation was found).\n" | 
					
						
							|  |  |  |     "\n"); | 
					
						
							|  |  |  | static PyObject *app_translations_pgettext(BlenderAppTranslations *UNUSED(self), | 
					
						
							|  |  |  |                                            PyObject *args, | 
					
						
							|  |  |  |                                            PyObject *kw) | 
					
						
							|  |  |  | { | 
					
						
							| 
									
										
										
										
											2015-08-16 17:32:01 +10:00
										 |  |  |   return _py_pgettext(args, kw, BLT_pgettext); | 
					
						
							| 
									
										
										
										
											2013-02-10 10:29:38 +00:00
										 |  |  | } | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2013-02-10 10:29:38 +00:00
										 |  |  | PyDoc_STRVAR(app_translations_pgettext_iface_doc, | 
					
						
							| 
									
										
										
										
											2020-07-29 10:01:42 +10:00
										 |  |  |              ".. method:: pgettext_iface(msgid, msgctxt=None)\n" | 
					
						
							| 
									
										
										
										
											2013-02-10 10:29:38 +00:00
										 |  |  |              "\n" | 
					
						
							|  |  |  |              "   Try to translate the given msgid (with optional msgctxt), if labels' translation " | 
					
						
							|  |  |  |              "is enabled.\n" | 
					
						
							| 
									
										
										
										
											2013-05-14 15:33:59 +00:00
										 |  |  |              "\n" | 
					
						
							|  |  |  |              "   .. note::\n" | 
					
						
							| 
									
										
										
										
											2018-11-14 09:04:24 +11:00
										 |  |  |              "      See :func:`pgettext` notes.\n" | 
					
						
							| 
									
										
										
										
											2013-02-10 10:29:38 +00:00
										 |  |  |              "\n" | 
					
						
							|  |  |  |              "   :arg msgid: The string to translate.\n" | 
					
						
							|  |  |  |              "   :type msgid: string\n" | 
					
						
							| 
									
										
										
										
											2015-08-16 17:32:01 +10:00
										 |  |  |              "   :arg msgctxt: The translation context (defaults to BLT_I18NCONTEXT_DEFAULT).\n" | 
					
						
							| 
									
										
										
										
											2013-02-10 10:29:38 +00:00
										 |  |  |              "   :type msgctxt: string or None\n" | 
					
						
							|  |  |  |              "   :return: The translated string (or msgid if no translation was found).\n" | 
					
						
							|  |  |  |              "\n"); | 
					
						
							|  |  |  | static PyObject *app_translations_pgettext_iface(BlenderAppTranslations *UNUSED(self), | 
					
						
							|  |  |  |                                                  PyObject *args, | 
					
						
							|  |  |  |                                                  PyObject *kw) | 
					
						
							|  |  |  | { | 
					
						
							| 
									
										
										
										
											2015-08-16 17:32:01 +10:00
										 |  |  |   return _py_pgettext(args, kw, BLT_translate_do_iface); | 
					
						
							| 
									
										
										
										
											2013-02-10 10:29:38 +00:00
										 |  |  | } | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2013-02-10 10:29:38 +00:00
										 |  |  | PyDoc_STRVAR(app_translations_pgettext_tip_doc, | 
					
						
							| 
									
										
										
										
											2020-07-29 10:01:42 +10:00
										 |  |  |              ".. method:: pgettext_tip(msgid, msgctxt=None)\n" | 
					
						
							| 
									
										
										
										
											2013-02-10 10:29:38 +00:00
										 |  |  |              "\n" | 
					
						
							|  |  |  |              "   Try to translate the given msgid (with optional msgctxt), if tooltips' " | 
					
						
							|  |  |  |              "translation is enabled.\n" | 
					
						
							| 
									
										
										
										
											2013-05-14 15:33:59 +00:00
										 |  |  |              "\n" | 
					
						
							|  |  |  |              "   .. note::\n" | 
					
						
							| 
									
										
										
										
											2018-11-14 09:04:24 +11:00
										 |  |  |              "      See :func:`pgettext` notes.\n" | 
					
						
							| 
									
										
										
										
											2013-02-10 10:29:38 +00:00
										 |  |  |              "\n" | 
					
						
							|  |  |  |              "   :arg msgid: The string to translate.\n" | 
					
						
							|  |  |  |              "   :type msgid: string\n" | 
					
						
							| 
									
										
										
										
											2015-08-16 17:32:01 +10:00
										 |  |  |              "   :arg msgctxt: The translation context (defaults to BLT_I18NCONTEXT_DEFAULT).\n" | 
					
						
							| 
									
										
										
										
											2013-02-10 10:29:38 +00:00
										 |  |  |              "   :type msgctxt: string or None\n" | 
					
						
							|  |  |  |              "   :return: The translated string (or msgid if no translation was found).\n" | 
					
						
							|  |  |  |              "\n"); | 
					
						
							|  |  |  | static PyObject *app_translations_pgettext_tip(BlenderAppTranslations *UNUSED(self), | 
					
						
							|  |  |  |                                                PyObject *args, | 
					
						
							|  |  |  |                                                PyObject *kw) | 
					
						
							|  |  |  | { | 
					
						
							| 
									
										
										
										
											2015-08-16 17:32:01 +10:00
										 |  |  |   return _py_pgettext(args, kw, BLT_translate_do_tooltip); | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2013-03-20 18:42:09 +00:00
										 |  |  | PyDoc_STRVAR(app_translations_pgettext_data_doc, | 
					
						
							| 
									
										
										
										
											2020-07-29 10:01:42 +10:00
										 |  |  |              ".. method:: pgettext_data(msgid, msgctxt=None)\n" | 
					
						
							| 
									
										
										
										
											2013-03-20 18:42:09 +00:00
										 |  |  |              "\n" | 
					
						
							|  |  |  |              "   Try to translate the given msgid (with optional msgctxt), if new data name's " | 
					
						
							|  |  |  |              "translation is enabled.\n" | 
					
						
							| 
									
										
										
										
											2013-05-14 15:33:59 +00:00
										 |  |  |              "\n" | 
					
						
							|  |  |  |              "   .. note::\n" | 
					
						
							| 
									
										
										
										
											2018-11-14 09:04:24 +11:00
										 |  |  |              "      See :func:`pgettext` notes.\n" | 
					
						
							| 
									
										
										
										
											2013-03-20 18:42:09 +00:00
										 |  |  |              "\n" | 
					
						
							|  |  |  |              "   :arg msgid: The string to translate.\n" | 
					
						
							|  |  |  |              "   :type msgid: string\n" | 
					
						
							| 
									
										
										
										
											2015-08-16 17:32:01 +10:00
										 |  |  |              "   :arg msgctxt: The translation context (defaults to BLT_I18NCONTEXT_DEFAULT).\n" | 
					
						
							| 
									
										
										
										
											2013-03-20 18:42:09 +00:00
										 |  |  |              "   :type msgctxt: string or None\n" | 
					
						
							| 
									
										
										
										
											2013-05-14 15:33:59 +00:00
										 |  |  |              "   :return: The translated string (or ``msgid`` if no translation was found).\n" | 
					
						
							| 
									
										
										
										
											2013-03-20 18:42:09 +00:00
										 |  |  |              "\n"); | 
					
						
							|  |  |  | static PyObject *app_translations_pgettext_data(BlenderAppTranslations *UNUSED(self), | 
					
						
							|  |  |  |                                                 PyObject *args, | 
					
						
							|  |  |  |                                                 PyObject *kw) | 
					
						
							|  |  |  | { | 
					
						
							| 
									
										
										
										
											2015-08-16 17:32:01 +10:00
										 |  |  |   return _py_pgettext(args, kw, BLT_translate_do_new_dataname); | 
					
						
							| 
									
										
										
										
											2013-03-20 18:42:09 +00:00
										 |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2013-01-21 10:57:24 +00:00
										 |  |  | PyDoc_STRVAR( | 
					
						
							|  |  |  |     app_translations_locale_explode_doc, | 
					
						
							|  |  |  |     ".. method:: locale_explode(locale)\n" | 
					
						
							|  |  |  |     "\n" | 
					
						
							|  |  |  |     "   Return all components and their combinations  of the given ISO locale string.\n" | 
					
						
							|  |  |  |     "\n" | 
					
						
							|  |  |  |     "   >>> bpy.app.translations.locale_explode(\"sr_RS@latin\")\n" | 
					
						
							|  |  |  |     "   (\"sr\", \"RS\", \"latin\", \"sr_RS\", \"sr@latin\")\n" | 
					
						
							|  |  |  |     "\n" | 
					
						
							|  |  |  |     "   For non-complete locales, missing elements will be None.\n" | 
					
						
							|  |  |  |     "\n" | 
					
						
							|  |  |  |     "   :arg locale: The ISO locale string to explode.\n" | 
					
						
							|  |  |  |     "   :type msgid: string\n" | 
					
						
							| 
									
										
										
										
											2013-05-14 15:33:59 +00:00
										 |  |  |     "   :return: A tuple ``(language, country, variant, language_country, language@variant)``.\n" | 
					
						
							| 
									
										
										
										
											2013-01-21 10:57:24 +00:00
										 |  |  |     "\n"); | 
					
						
							|  |  |  | static PyObject *app_translations_locale_explode(BlenderAppTranslations *UNUSED(self), | 
					
						
							|  |  |  |                                                  PyObject *args, | 
					
						
							|  |  |  |                                                  PyObject *kw) | 
					
						
							|  |  |  | { | 
					
						
							| 
									
										
										
										
											2014-12-27 17:24:39 +01:00
										 |  |  |   PyObject *ret_tuple; | 
					
						
							| 
									
										
										
										
											2013-01-21 10:57:24 +00:00
										 |  |  |   static const char *kwlist[] = {"locale", NULL}; | 
					
						
							|  |  |  |   const char *locale; | 
					
						
							|  |  |  |   char *language, *country, *variant, *language_country, *language_variant; | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2013-01-22 11:23:05 +00:00
										 |  |  |   if (!PyArg_ParseTupleAndKeywords( | 
					
						
							|  |  |  |           args, kw, "s:bpy.app.translations.locale_explode", (char **)kwlist, &locale)) { | 
					
						
							| 
									
										
										
										
											2013-01-21 10:57:24 +00:00
										 |  |  |     return NULL; | 
					
						
							|  |  |  |   } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2015-08-16 17:32:01 +10:00
										 |  |  |   BLT_lang_locale_explode( | 
					
						
							|  |  |  |       locale, &language, &country, &variant, &language_country, &language_variant); | 
					
						
							| 
									
										
										
										
											2013-01-21 10:57:24 +00:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2014-12-27 17:24:39 +01:00
										 |  |  |   ret_tuple = Py_BuildValue( | 
					
						
							|  |  |  |       "sssss", language, country, variant, language_country, language_variant); | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |   MEM_SAFE_FREE(language); | 
					
						
							|  |  |  |   MEM_SAFE_FREE(country); | 
					
						
							|  |  |  |   MEM_SAFE_FREE(variant); | 
					
						
							|  |  |  |   MEM_SAFE_FREE(language_country); | 
					
						
							|  |  |  |   MEM_SAFE_FREE(language_variant); | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |   return ret_tuple; | 
					
						
							| 
									
										
										
										
											2013-01-21 10:57:24 +00:00
										 |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2013-03-22 05:34:10 +00:00
										 |  |  | static PyMethodDef app_translations_methods[] = { | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |     /* Can't use METH_KEYWORDS alone, see http://bugs.python.org/issue11587 */ | 
					
						
							| 
									
										
										
										
											2013-03-20 18:42:09 +00:00
										 |  |  |     {"register", | 
					
						
							|  |  |  |      (PyCFunction)app_translations_py_messages_register, | 
					
						
							|  |  |  |      METH_VARARGS | METH_KEYWORDS, | 
					
						
							|  |  |  |      app_translations_py_messages_register_doc}, | 
					
						
							|  |  |  |     {"unregister", | 
					
						
							|  |  |  |      (PyCFunction)app_translations_py_messages_unregister, | 
					
						
							|  |  |  |      METH_VARARGS | METH_KEYWORDS, | 
					
						
							|  |  |  |      app_translations_py_messages_unregister_doc}, | 
					
						
							|  |  |  |     {"pgettext", | 
					
						
							|  |  |  |      (PyCFunction)app_translations_pgettext, | 
					
						
							|  |  |  |      METH_VARARGS | METH_KEYWORDS | METH_STATIC, | 
					
						
							|  |  |  |      app_translations_pgettext_doc}, | 
					
						
							|  |  |  |     {"pgettext_iface", | 
					
						
							|  |  |  |      (PyCFunction)app_translations_pgettext_iface, | 
					
						
							|  |  |  |      METH_VARARGS | METH_KEYWORDS | METH_STATIC, | 
					
						
							|  |  |  |      app_translations_pgettext_iface_doc}, | 
					
						
							|  |  |  |     {"pgettext_tip", | 
					
						
							|  |  |  |      (PyCFunction)app_translations_pgettext_tip, | 
					
						
							|  |  |  |      METH_VARARGS | METH_KEYWORDS | METH_STATIC, | 
					
						
							|  |  |  |      app_translations_pgettext_tip_doc}, | 
					
						
							|  |  |  |     {"pgettext_data", | 
					
						
							|  |  |  |      (PyCFunction)app_translations_pgettext_data, | 
					
						
							|  |  |  |      METH_VARARGS | METH_KEYWORDS | METH_STATIC, | 
					
						
							|  |  |  |      app_translations_pgettext_data_doc}, | 
					
						
							|  |  |  |     {"locale_explode", | 
					
						
							|  |  |  |      (PyCFunction)app_translations_locale_explode, | 
					
						
							|  |  |  |      METH_VARARGS | METH_KEYWORDS | METH_STATIC, | 
					
						
							|  |  |  |      app_translations_locale_explode_doc}, | 
					
						
							| 
									
										
										
										
											2019-02-03 14:01:45 +11:00
										 |  |  |     {NULL}, | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | }; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | static PyObject *app_translations_new(PyTypeObject *type, | 
					
						
							|  |  |  |                                       PyObject *UNUSED(args), | 
					
						
							|  |  |  |                                       PyObject *UNUSED(kw)) | 
					
						
							|  |  |  | { | 
					
						
							|  |  |  |   /*  printf("%s (%p)\n", __func__, _translations); */ | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |   if (!_translations) { | 
					
						
							|  |  |  |     _translations = (BlenderAppTranslations *)type->tp_alloc(type, 0); | 
					
						
							|  |  |  |     if (_translations) { | 
					
						
							|  |  |  |       PyObject *py_ctxts; | 
					
						
							| 
									
										
										
										
											2015-08-16 17:32:01 +10:00
										 |  |  |       BLT_i18n_contexts_descriptor *ctxt; | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |       _translations->contexts = app_translations_contexts_make(); | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
										
										
											2016-07-31 17:22:04 +10:00
										 |  |  |       py_ctxts = _PyDict_NewPresized(ARRAY_SIZE(_contexts)); | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |       for (ctxt = _contexts; ctxt->c_id; ctxt++) { | 
					
						
							|  |  |  |         PyObject *val = PyUnicode_FromString(ctxt->py_id); | 
					
						
							|  |  |  |         PyDict_SetItemString(py_ctxts, ctxt->c_id, val); | 
					
						
							|  |  |  |         Py_DECREF(val); | 
					
						
							|  |  |  |       } | 
					
						
							|  |  |  |       _translations->contexts_C_to_py = PyDictProxy_New(py_ctxts); | 
					
						
							|  |  |  |       Py_DECREF(py_ctxts); /* The actual dict is only owned by its proxy */ | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |       _translations->py_messages = PyDict_New(); | 
					
						
							|  |  |  |     } | 
					
						
							|  |  |  |   } | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |   return (PyObject *)_translations; | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2013-01-24 13:43:37 +00:00
										 |  |  | static void app_translations_free(void *obj) | 
					
						
							| 
									
										
										
										
											2013-01-24 11:38:17 +00:00
										 |  |  | { | 
					
						
							|  |  |  |   PyObject_Del(obj); | 
					
						
							|  |  |  | #ifdef WITH_INTERNATIONAL
 | 
					
						
							|  |  |  |   _clear_translations_cache(); | 
					
						
							|  |  |  | #endif
 | 
					
						
							|  |  |  | } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | PyDoc_STRVAR(app_translations_doc, | 
					
						
							| 
									
										
										
										
											2013-05-14 15:33:59 +00:00
										 |  |  |              "This object contains some data/methods regarding internationalization in Blender, " | 
					
						
							|  |  |  |              "and allows every py script\n" | 
					
						
							|  |  |  |              "to feature translations for its own UI messages.\n" | 
					
						
							|  |  |  |              "\n"); | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | static PyTypeObject BlenderAppTranslationsType = { | 
					
						
							|  |  |  |     PyVarObject_HEAD_INIT(NULL, 0) | 
					
						
							|  |  |  |     /* tp_name */ | 
					
						
							| 
									
										
										
										
											2013-03-20 18:42:09 +00:00
										 |  |  |     "bpy.app._translations_type", | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |     /* tp_basicsize */ | 
					
						
							|  |  |  |     sizeof(BlenderAppTranslations), | 
					
						
							|  |  |  |     0, /* tp_itemsize */ | 
					
						
							|  |  |  |     /* methods */ | 
					
						
							|  |  |  |     /* No destructor, this is a singleton! */ | 
					
						
							| 
									
										
										
										
											2019-10-16 14:44:36 +11:00
										 |  |  |     NULL, /* tp_dealloc */ | 
					
						
							| 
									
										
										
										
											2021-02-12 08:08:15 +11:00
										 |  |  |     0,    /* tp_vectorcall_offset */ | 
					
						
							| 
									
										
										
										
											2019-10-16 14:44:36 +11:00
										 |  |  |     NULL, /* getattrfunc tp_getattr; */ | 
					
						
							|  |  |  |     NULL, /* setattrfunc tp_setattr; */ | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |     NULL, | 
					
						
							|  |  |  |     /* tp_compare */ /* DEPRECATED in python 3.0! */ | 
					
						
							|  |  |  |     NULL,            /* tp_repr */ | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |     /* Method suites for standard classes */ | 
					
						
							|  |  |  |     NULL, /* PyNumberMethods *tp_as_number; */ | 
					
						
							|  |  |  |     NULL, /* PySequenceMethods *tp_as_sequence; */ | 
					
						
							|  |  |  |     NULL, /* PyMappingMethods *tp_as_mapping; */ | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |     /* More standard operations (here for binary compatibility) */ | 
					
						
							|  |  |  |     NULL, /* hashfunc tp_hash; */ | 
					
						
							|  |  |  |     NULL, /* ternaryfunc tp_call; */ | 
					
						
							|  |  |  |     NULL, /* reprfunc tp_str; */ | 
					
						
							|  |  |  |     NULL, /* getattrofunc tp_getattro; */ | 
					
						
							|  |  |  |     NULL, /* setattrofunc tp_setattro; */ | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |     /* Functions to access object as input/output buffer */ | 
					
						
							|  |  |  |     NULL, /* PyBufferProcs *tp_as_buffer; */ | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |     /*** Flags to define presence of optional/expanded features ***/ | 
					
						
							|  |  |  |     Py_TPFLAGS_DEFAULT, /* long tp_flags; */ | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |     app_translations_doc, /* char *tp_doc;  Documentation string */ | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |     /*** Assigned meaning in release 2.0 ***/ | 
					
						
							|  |  |  |     /* call function for all accessible objects */ | 
					
						
							|  |  |  |     NULL, /* traverseproc tp_traverse; */ | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |     /* delete references to contained objects */ | 
					
						
							|  |  |  |     NULL, /* inquiry tp_clear; */ | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |     /***  Assigned meaning in release 2.1 ***/ | 
					
						
							|  |  |  |     /*** rich comparisons ***/ | 
					
						
							|  |  |  |     NULL, /* richcmpfunc tp_richcompare; */ | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |     /***  weak reference enabler ***/ | 
					
						
							|  |  |  |     0, /* long tp_weaklistoffset */ | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |     /*** Added in release 2.2 ***/ | 
					
						
							|  |  |  |     /*   Iterators */ | 
					
						
							|  |  |  |     NULL, /* getiterfunc tp_iter; */ | 
					
						
							|  |  |  |     NULL, /* iternextfunc tp_iternext; */ | 
					
						
							| 
									
										
										
										
											2019-04-17 06:17:24 +02:00
										 |  |  | 
 | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |     /*** Attribute descriptor and subclassing stuff ***/ | 
					
						
							|  |  |  |     app_translations_methods,   /* struct PyMethodDef *tp_methods; */ | 
					
						
							|  |  |  |     app_translations_members,   /* struct PyMemberDef *tp_members; */ | 
					
						
							|  |  |  |     app_translations_getseters, /* struct PyGetSetDef *tp_getset; */ | 
					
						
							|  |  |  |     NULL,                       /* struct _typeobject *tp_base; */ | 
					
						
							|  |  |  |     NULL,                       /* PyObject *tp_dict; */ | 
					
						
							|  |  |  |     NULL,                       /* descrgetfunc tp_descr_get; */ | 
					
						
							|  |  |  |     NULL,                       /* descrsetfunc tp_descr_set; */ | 
					
						
							|  |  |  |     0,                          /* long tp_dictoffset; */ | 
					
						
							|  |  |  |     NULL,                       /* initproc tp_init; */ | 
					
						
							|  |  |  |     NULL,                       /* allocfunc tp_alloc; */ | 
					
						
							|  |  |  |                                 /* newfunc tp_new; */ | 
					
						
							|  |  |  |     (newfunc)app_translations_new, | 
					
						
							|  |  |  |     /*  Low-level free-memory routine */ | 
					
						
							| 
									
										
										
										
											2013-01-25 21:21:38 +00:00
										 |  |  |     app_translations_free, /* freefunc tp_free;  */ | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |     /* For PyObject_IS_GC */ | 
					
						
							|  |  |  |     NULL, /* inquiry tp_is_gc;  */ | 
					
						
							|  |  |  |     NULL, /* PyObject *tp_bases; */ | 
					
						
							|  |  |  |     /* method resolution order */ | 
					
						
							|  |  |  |     NULL, /* PyObject *tp_mro;  */ | 
					
						
							|  |  |  |     NULL, /* PyObject *tp_cache; */ | 
					
						
							|  |  |  |     NULL, /* PyObject *tp_subclasses; */ | 
					
						
							|  |  |  |     NULL, /* PyObject *tp_weaklist; */ | 
					
						
							| 
									
										
										
										
											2019-01-19 13:21:18 +11:00
										 |  |  |     NULL, | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | }; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  | PyObject *BPY_app_translations_struct(void) | 
					
						
							|  |  |  | { | 
					
						
							|  |  |  |   PyObject *ret; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |   /* Let's finalize our contexts structseq definition! */ | 
					
						
							|  |  |  |   { | 
					
						
							| 
									
										
										
										
											2015-08-16 17:32:01 +10:00
										 |  |  |     BLT_i18n_contexts_descriptor *ctxt; | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |     PyStructSequence_Field *desc; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |     /* We really populate the contexts' fields here! */ | 
					
						
							|  |  |  |     for (ctxt = _contexts, desc = app_translations_contexts_desc.fields; ctxt->c_id; | 
					
						
							|  |  |  |          ctxt++, desc++) { | 
					
						
							| 
									
										
										
										
											2019-12-20 10:42:57 +11:00
										 |  |  |       desc->name = ctxt->py_id; | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |       desc->doc = NULL; | 
					
						
							|  |  |  |     } | 
					
						
							|  |  |  |     desc->name = desc->doc = NULL; /* End sentinel! */ | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |     PyStructSequence_InitType(&BlenderAppTranslationsContextsType, | 
					
						
							|  |  |  |                               &app_translations_contexts_desc); | 
					
						
							|  |  |  |   } | 
					
						
							|  |  |  | 
 | 
					
						
							| 
									
										
										
										
											2019-03-30 06:12:48 +11:00
										 |  |  |   if (PyType_Ready(&BlenderAppTranslationsType) < 0) { | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |     return NULL; | 
					
						
							| 
									
										
										
										
											2019-03-30 06:12:48 +11:00
										 |  |  |   } | 
					
						
							| 
									
										
											  
											
												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
										 |  |  | 
 | 
					
						
							|  |  |  |   ret = PyObject_CallObject((PyObject *)&BlenderAppTranslationsType, NULL); | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |   /* prevent user from creating new instances */ | 
					
						
							|  |  |  |   BlenderAppTranslationsType.tp_new = NULL; | 
					
						
							| 
									
										
										
										
											2020-09-30 20:09:02 +10:00
										 |  |  |   /* without this we can't do set(sys.modules) T29635. */ | 
					
						
							| 
									
										
											  
											
												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
										 |  |  |   BlenderAppTranslationsType.tp_hash = (hashfunc)_Py_HashPointer; | 
					
						
							|  |  |  | 
 | 
					
						
							|  |  |  |   return ret; | 
					
						
							|  |  |  | } | 
					
						
							| 
									
										
										
										
											2015-04-01 09:34:01 +02:00
										 |  |  | 
 | 
					
						
							|  |  |  | void BPY_app_translations_end(void) | 
					
						
							|  |  |  | { | 
					
						
							| 
									
										
										
										
											2019-08-17 00:54:22 +10:00
										 |  |  |   /* In case the object remains in a module's name-space, see T44127. */ | 
					
						
							| 
									
										
										
										
											2015-04-01 09:34:01 +02:00
										 |  |  | #ifdef WITH_INTERNATIONAL
 | 
					
						
							|  |  |  |   _clear_translations_cache(); | 
					
						
							|  |  |  | #endif
 | 
					
						
							|  |  |  | } | 
					
						
							| 
									
										
										
										
											2020-03-26 10:24:44 +11:00
										 |  |  | 
 | 
					
						
							|  |  |  | /** \} */ |