2023-06-15 03:09:04 +00:00
|
|
|
/* SPDX-FileCopyrightText: 2012 Blender Foundation
|
|
|
|
*
|
|
|
|
* SPDX-License-Identifier: GPL-2.0-or-later */
|
2012-11-11 16:54:26 +00:00
|
|
|
|
2021-12-14 07:35:31 +00:00
|
|
|
/** \file
|
|
|
|
* \ingroup intern_locale
|
|
|
|
*/
|
|
|
|
|
2012-11-11 16:54:26 +00:00
|
|
|
#include <boost/locale.hpp>
|
2023-01-04 14:23:26 +00:00
|
|
|
#include <iostream>
|
2020-03-19 08:33:03 +00:00
|
|
|
#include <stdio.h>
|
2012-11-11 16:54:26 +00:00
|
|
|
|
|
|
|
#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
|
|
|
|
2021-11-01 03:00:58 +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
|
2018-11-24 18:21:35 +00:00
|
|
|
* once deleted (which happens as soons they are out of scope of this func). */
|
|
|
|
typedef boost::locale::message_format<char> char_message_facet;
|
|
|
|
static std::locale locale_global;
|
|
|
|
static char_message_facet const *facet_global = NULL;
|
|
|
|
|
|
|
|
static void bl_locale_global_cache()
|
|
|
|
{
|
|
|
|
/* Cache facet in global variable. Not only is it better for performance,
|
|
|
|
* it also fixes crashes on macOS when doing translation from threads other
|
|
|
|
* than main. Likely because of some internal thread local variables. */
|
|
|
|
try {
|
|
|
|
/* facet_global reference is valid as long as local_global exists,
|
|
|
|
* so we store both. */
|
|
|
|
locale_global = std::locale();
|
|
|
|
facet_global = &std::use_facet<char_message_facet>(locale_global);
|
|
|
|
}
|
2023-05-01 23:32:44 +00:00
|
|
|
/* `if std::has_facet<char_message_facet>(l) == false`, LC_ALL = "C" case. */
|
|
|
|
catch (const std::bad_cast &e) {
|
2018-11-24 18:21:35 +00:00
|
|
|
#ifndef NDEBUG
|
|
|
|
std::cout << "bl_locale_global_cache:" << e.what() << " \n";
|
|
|
|
#endif
|
|
|
|
(void)e;
|
|
|
|
facet_global = NULL;
|
|
|
|
}
|
|
|
|
catch (const std::exception &e) {
|
|
|
|
#ifndef NDEBUG
|
|
|
|
std::cout << "bl_locale_global_cache:" << e.what() << " \n";
|
|
|
|
#endif
|
|
|
|
(void)e;
|
|
|
|
facet_global = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-11-11 16:54:26 +00:00
|
|
|
void bl_locale_init(const char *_messages_path, const char *_default_domain)
|
|
|
|
{
|
2021-11-01 03:00:58 +00:00
|
|
|
/* Avoid using ICU backend, we do not need its power and it's rather heavy! */
|
2012-11-11 16:54:26 +00:00
|
|
|
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;
|
2021-11-01 03:00:58 +00:00
|
|
|
/* Specify location of dictionaries. */
|
2012-11-11 16:54:26 +00:00
|
|
|
gen.add_messages_path(messages_path);
|
|
|
|
gen.add_messages_domain(default_domain);
|
2019-05-01 10:50:02 +00:00
|
|
|
// gen.set_default_messages_domain(default_domain);
|
2019-04-17 04:17:24 +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 {
|
2014-04-01 22:01:48 +00:00
|
|
|
#if defined(__APPLE__) && !defined(WITH_HEADLESS) && !defined(WITH_GHOST_SDL)
|
2014-10-07 20:46:19 +00:00
|
|
|
std::string locale_osx = osx_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);
|
2021-11-01 03:00:58 +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
|
|
|
|
2018-11-24 18:21:35 +00:00
|
|
|
bl_locale_global_cache();
|
|
|
|
|
2021-11-01 03:00:58 +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
|
|
|
}
|
2021-11-01 03:00:58 +00:00
|
|
|
/* Extra catch on `std::runtime_error` is needed for macOS/Clang as it seems that exceptions
|
|
|
|
* like `boost::locale::conv::conversion_error` (which inherit from `std::runtime_error`) are
|
2023-02-12 03:37:16 +00:00
|
|
|
* not caught by their ancestor `std::exception`. See #88877#1177108 */
|
2021-10-29 08:11:04 +00:00
|
|
|
catch (std::runtime_error const &e) {
|
|
|
|
std::cout << "bl_locale_set(" << locale << "): " << e.what() << " \n";
|
|
|
|
}
|
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
|
|
|
{
|
2018-11-24 18:21:35 +00:00
|
|
|
if (facet_global) {
|
|
|
|
char const *r = facet_global->get(0, msgctxt, msgid);
|
|
|
|
if (r) {
|
2012-11-11 16:54:26 +00:00
|
|
|
return r;
|
2018-11-24 18:21:35 +00:00
|
|
|
}
|
2012-11-11 16:54:26 +00:00
|
|
|
}
|
2019-04-17 04:17:24 +00:00
|
|
|
|
2018-11-24 18:21:35 +00:00
|
|
|
return msgid;
|
2013-06-21 12:33:19 +00:00
|
|
|
}
|