2012-11-11 16:54:26 +00:00
|
|
|
/*
|
|
|
|
* ***** BEGIN GPL LICENSE BLOCK *****
|
|
|
|
*
|
|
|
|
* 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.
|
|
|
|
*
|
|
|
|
* The Original Code is Copyright (C) 2012, Blender Foundation
|
|
|
|
* All rights reserved.
|
|
|
|
*
|
|
|
|
* The Original Code is: all of this file.
|
|
|
|
*
|
|
|
|
* Contributor(s): Bastien Montagne.
|
|
|
|
*
|
|
|
|
* ***** END GPL LICENSE BLOCK *****
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
2012-11-21 15:14:19 +00:00
|
|
|
#include <stdio.h>
|
2012-11-11 16:54:26 +00:00
|
|
|
#include <boost/locale.hpp>
|
|
|
|
|
|
|
|
#include "boost_locale_wrapper.h"
|
|
|
|
|
|
|
|
static std::string messages_path;
|
|
|
|
static std::string default_domain;
|
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 std::string locale_str;
|
2012-11-11 16:54:26 +00:00
|
|
|
|
|
|
|
void bl_locale_init(const char *_messages_path, const char *_default_domain)
|
|
|
|
{
|
|
|
|
// Avoid using ICU backend, we do not need its power and it's rather heavy!
|
|
|
|
boost::locale::localization_backend_manager lman = boost::locale::localization_backend_manager::global();
|
|
|
|
#if defined (_WIN32)
|
|
|
|
lman.select("winapi");
|
|
|
|
#else
|
|
|
|
lman.select("posix");
|
|
|
|
#endif
|
|
|
|
boost::locale::localization_backend_manager::global(lman);
|
|
|
|
|
|
|
|
messages_path = _messages_path;
|
|
|
|
default_domain = _default_domain;
|
|
|
|
}
|
|
|
|
|
|
|
|
void bl_locale_set(const char *locale)
|
|
|
|
{
|
|
|
|
boost::locale::generator gen;
|
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
|
|
|
std::locale _locale;
|
2012-11-11 16:54:26 +00:00
|
|
|
// Specify location of dictionaries.
|
|
|
|
gen.add_messages_path(messages_path);
|
|
|
|
gen.add_messages_domain(default_domain);
|
2012-12-31 12:12:50 +00:00
|
|
|
//gen.set_default_messages_domain(default_domain);
|
2012-11-21 15:14:19 +00:00
|
|
|
|
2012-12-31 12:12:50 +00:00
|
|
|
try {
|
|
|
|
if (locale && locale[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
|
|
|
_locale = gen(locale);
|
2012-12-31 12:12:50 +00:00
|
|
|
}
|
|
|
|
else {
|
|
|
|
#ifdef __APPLE__
|
2013-06-27 13:24:55 +00:00
|
|
|
extern char GHOST_user_locale[128]; // pulled from Ghost_SystemCocoa
|
|
|
|
std::string locale_osx = GHOST_user_locale + std::string(".UTF-8");
|
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
|
|
|
_locale = gen(locale_osx.c_str());
|
2012-11-21 15:14:19 +00:00
|
|
|
#else
|
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
|
|
|
_locale = gen("");
|
2012-11-21 15:14:19 +00:00
|
|
|
#endif
|
2012-12-31 12:12:50 +00:00
|
|
|
}
|
2013-05-01 17:49:19 +00:00
|
|
|
std::locale::global(_locale);
|
2012-12-31 12:12:50 +00:00
|
|
|
// Note: boost always uses "C" LC_NUMERIC by default!
|
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-05-01 17:49:19 +00:00
|
|
|
// Generate the locale string (useful to know which locale we are actually using in case of "default" one).
|
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 LOCALE_INFO std::use_facet<boost::locale::info>(_locale)
|
|
|
|
|
2013-05-01 17:11:07 +00:00
|
|
|
locale_str = LOCALE_INFO.language();
|
|
|
|
if (LOCALE_INFO.country() != "") {
|
|
|
|
locale_str += "_" + LOCALE_INFO.country();
|
|
|
|
}
|
|
|
|
if (LOCALE_INFO.variant() != "") {
|
|
|
|
locale_str += "@" + LOCALE_INFO.variant();
|
|
|
|
}
|
|
|
|
|
|
|
|
#undef LOCALE_INFO
|
|
|
|
|
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-05-01 17:11:07 +00:00
|
|
|
catch(std::exception const &e) {
|
|
|
|
std::cout << "bl_locale_set(" << locale << "): " << e.what() << " \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
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
const char *bl_locale_get(void)
|
|
|
|
{
|
|
|
|
return locale_str.c_str();
|
2012-11-11 16:54:26 +00:00
|
|
|
}
|
|
|
|
|
2012-12-31 12:12:50 +00:00
|
|
|
const char *bl_locale_pgettext(const char *msgctxt, const char *msgid)
|
2012-11-11 16:54:26 +00:00
|
|
|
{
|
|
|
|
// Note: We cannot use short stuff like boost::locale::gettext, because those return
|
|
|
|
// std::basic_string objects, which c_ptr()-returned char* is no more valid
|
|
|
|
// once deleted (which happens as soons they are out of scope of this func).
|
|
|
|
typedef boost::locale::message_format<char> char_message_facet;
|
|
|
|
try {
|
|
|
|
std::locale l;
|
|
|
|
char_message_facet const &facet = std::use_facet<char_message_facet>(l);
|
|
|
|
char const *r = facet.get(0, msgctxt, msgid);
|
|
|
|
if(r)
|
|
|
|
return r;
|
|
|
|
return msgid;
|
|
|
|
}
|
2013-06-21 12:33:19 +00:00
|
|
|
catch(std::exception const &) {
|
2012-12-31 12:12:50 +00:00
|
|
|
// std::cout << "bl_locale_pgettext(" << msgctxt << ", " << msgid << "): " << e.what() << " \n";
|
2012-11-11 16:54:26 +00:00
|
|
|
return msgid;
|
|
|
|
}
|
2013-06-21 12:33:19 +00:00
|
|
|
}
|