2011-02-23 10:52:22 +00:00
|
|
|
/*
|
2009-01-29 05:19:27 +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
|
2018-06-01 18:19:39 +02:00
|
|
|
* of the License, or (at your option) any later version.
|
2009-01-29 05:19:27 +00:00
|
|
|
*
|
|
|
|
|
* 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,
|
2010-02-12 13:34:04 +00:00
|
|
|
* Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
2009-01-29 05:19:27 +00:00
|
|
|
*
|
|
|
|
|
* The Original Code is Copyright (C) 2008 Blender Foundation.
|
|
|
|
|
* All rights reserved.
|
|
|
|
|
*/
|
|
|
|
|
|
2019-02-18 08:08:12 +11:00
|
|
|
/** \file
|
|
|
|
|
* \ingroup blt
|
2014-01-19 23:14:24 +11:00
|
|
|
*
|
|
|
|
|
* Main internationalization functions to set the locale and query available languages.
|
2011-02-27 20:42:42 +00:00
|
|
|
*/
|
|
|
|
|
|
2013-01-21 05:42:19 +00:00
|
|
|
#include <stdio.h>
|
|
|
|
|
#include <stdlib.h>
|
2013-01-21 08:08:20 +00:00
|
|
|
#include <string.h>
|
2013-01-21 05:42:19 +00:00
|
|
|
|
2015-02-03 17:34:05 +05:00
|
|
|
#ifndef _WIN32
|
|
|
|
|
# include <locale.h>
|
|
|
|
|
#endif
|
|
|
|
|
|
2013-01-21 05:42:19 +00:00
|
|
|
#include "RNA_types.h"
|
2011-02-27 20:42:42 +00:00
|
|
|
|
2015-08-19 10:09:08 +02:00
|
|
|
#include "BLT_lang.h" /* own include */
|
2020-03-19 09:33:03 +01:00
|
|
|
#include "BLT_translation.h"
|
2011-11-14 16:05:44 +00:00
|
|
|
|
2013-01-21 08:08:20 +00:00
|
|
|
#include "BLI_path_util.h"
|
|
|
|
|
#include "BLI_string.h"
|
2015-08-19 10:09:08 +02:00
|
|
|
#include "BLI_utildefines.h"
|
2012-11-11 16:54:26 +00:00
|
|
|
|
2014-11-23 14:37:13 +01:00
|
|
|
#include "BKE_appdir.h"
|
2009-02-17 16:56:29 +00:00
|
|
|
|
2019-07-29 14:10:54 +02:00
|
|
|
#include "IMB_thumbs.h"
|
|
|
|
|
|
2011-07-22 14:14:28 +00:00
|
|
|
#include "DNA_userdef_types.h"
|
2009-01-29 05:19:27 +00:00
|
|
|
|
2011-02-13 03:21:27 +00:00
|
|
|
#include "MEM_guardedalloc.h"
|
2011-01-07 19:18:31 +00:00
|
|
|
|
2016-05-03 16:56:52 +02:00
|
|
|
/* Cached IME support flags */
|
|
|
|
|
static bool ime_is_lang_supported = false;
|
|
|
|
|
static void blt_lang_check_ime_supported(void);
|
|
|
|
|
|
2013-01-21 08:08:20 +00:00
|
|
|
#ifdef WITH_INTERNATIONAL
|
|
|
|
|
|
2019-01-26 20:41:52 +11:00
|
|
|
# include "BLI_fileops.h"
|
|
|
|
|
# include "BLI_linklist.h"
|
|
|
|
|
|
2013-01-21 08:08:20 +00:00
|
|
|
# include "boost_locale_wrapper.h"
|
2009-01-29 05:19:27 +00:00
|
|
|
|
2012-09-25 06:11:32 +00:00
|
|
|
/* Locale options. */
|
2012-10-22 14:04:40 +00:00
|
|
|
static const char **locales = NULL;
|
|
|
|
|
static int num_locales = 0;
|
|
|
|
|
static EnumPropertyItem *locales_menu = NULL;
|
|
|
|
|
static int num_locales_menu = 0;
|
|
|
|
|
|
|
|
|
|
static void free_locales(void)
|
|
|
|
|
{
|
|
|
|
|
if (locales) {
|
|
|
|
|
int idx = num_locales_menu - 1; /* Last item does not need to be freed! */
|
|
|
|
|
while (idx--) {
|
2012-11-09 16:15:00 +00:00
|
|
|
MEM_freeN((void *)locales_menu[idx].identifier);
|
|
|
|
|
MEM_freeN((void *)locales_menu[idx].name);
|
|
|
|
|
MEM_freeN((void *)locales_menu[idx].description); /* Also frees locales's relevant value! */
|
2012-10-22 14:04:40 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2013-06-21 12:33:19 +00:00
|
|
|
MEM_freeN((void *)locales);
|
2012-10-23 19:39:32 +00:00
|
|
|
locales = NULL;
|
|
|
|
|
}
|
|
|
|
|
if (locales_menu) {
|
2012-10-22 14:04:40 +00:00
|
|
|
MEM_freeN(locales_menu);
|
2012-10-23 19:39:32 +00:00
|
|
|
locales_menu = NULL;
|
2012-10-22 14:04:40 +00:00
|
|
|
}
|
|
|
|
|
num_locales = num_locales_menu = 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void fill_locales(void)
|
|
|
|
|
{
|
2014-11-23 15:54:29 +01:00
|
|
|
const char *const languages_path = BKE_appdir_folder_id(BLENDER_DATAFILES, "locale");
|
2013-03-05 03:17:46 +00:00
|
|
|
char languages[FILE_MAX];
|
2012-10-22 14:04:40 +00:00
|
|
|
LinkNode *lines = NULL, *line;
|
|
|
|
|
char *str;
|
|
|
|
|
int idx = 0;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-10-22 14:04:40 +00:00
|
|
|
free_locales();
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2013-03-05 03:17:46 +00:00
|
|
|
BLI_join_dirfile(languages, FILE_MAX, languages_path, "languages");
|
|
|
|
|
line = lines = BLI_file_read_as_lines(languages);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2015-09-14 02:21:15 +10:00
|
|
|
/* This whole "parsing" code is a bit weak, in that it expects strictly formatted input file...
|
2012-10-22 14:04:40 +00:00
|
|
|
* Should not be a problem, though, as this file is script-generated! */
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-10-22 14:04:40 +00:00
|
|
|
/* First loop to find highest locale ID */
|
|
|
|
|
while (line) {
|
|
|
|
|
int t;
|
2012-12-28 14:19:05 +00:00
|
|
|
str = (char *)line->link;
|
2020-11-06 12:30:59 +11:00
|
|
|
if (ELEM(str[0], '#', '\0')) {
|
2012-10-22 14:04:40 +00:00
|
|
|
line = line->next;
|
|
|
|
|
continue; /* Comment or void... */
|
|
|
|
|
}
|
|
|
|
|
t = atoi(str);
|
2019-04-22 12:20:14 +10:00
|
|
|
if (t >= num_locales) {
|
2012-10-22 14:04:40 +00:00
|
|
|
num_locales = t + 1;
|
2019-04-22 12:20:14 +10:00
|
|
|
}
|
2012-10-22 14:04:40 +00:00
|
|
|
num_locales_menu++;
|
|
|
|
|
line = line->next;
|
|
|
|
|
}
|
|
|
|
|
num_locales_menu++; /* The "closing" void item... */
|
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
|
|
|
/* And now, build locales and locale_menu! */
|
2012-10-22 14:04:40 +00:00
|
|
|
locales_menu = MEM_callocN(num_locales_menu * sizeof(EnumPropertyItem), __func__);
|
|
|
|
|
line = lines;
|
2019-04-22 01:50:49 +10:00
|
|
|
/* Do not allocate locales with zero-sized mem,
|
|
|
|
|
* as LOCALE macro uses NULL locales as invalid marker! */
|
2012-10-23 19:39:32 +00:00
|
|
|
if (num_locales > 0) {
|
2012-12-28 14:19:05 +00:00
|
|
|
locales = MEM_callocN(num_locales * sizeof(char *), __func__);
|
2012-10-23 19:39:32 +00:00
|
|
|
while (line) {
|
|
|
|
|
int id;
|
2012-11-02 20:03:15 +00:00
|
|
|
char *loc, *sep1, *sep2, *sep3;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-12-28 14:19:05 +00:00
|
|
|
str = (char *)line->link;
|
2020-11-06 12:30:59 +11:00
|
|
|
if (ELEM(str[0], '#', '\0')) {
|
2012-10-23 19:39:32 +00:00
|
|
|
line = line->next;
|
|
|
|
|
continue;
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-10-23 19:39:32 +00:00
|
|
|
id = atoi(str);
|
|
|
|
|
sep1 = strchr(str, ':');
|
|
|
|
|
if (sep1) {
|
|
|
|
|
sep1++;
|
|
|
|
|
sep2 = strchr(sep1, ':');
|
|
|
|
|
if (sep2) {
|
2012-11-02 20:03:15 +00:00
|
|
|
locales_menu[idx].value = id;
|
|
|
|
|
locales_menu[idx].icon = 0;
|
|
|
|
|
locales_menu[idx].name = BLI_strdupn(sep1, sep2 - sep1);
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-11-02 20:03:15 +00:00
|
|
|
sep2++;
|
|
|
|
|
sep3 = strchr(sep2, ':');
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-11-02 20:03:15 +00:00
|
|
|
if (sep3) {
|
|
|
|
|
locales_menu[idx].identifier = loc = BLI_strdupn(sep2, sep3 - sep2);
|
2012-11-11 16:54:26 +00:00
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
locales_menu[idx].identifier = loc = BLI_strdup(sep2);
|
|
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-11-11 16:54:26 +00:00
|
|
|
if (id == 0) {
|
2018-11-21 12:06:59 +01:00
|
|
|
/* The DEFAULT/Automatic item... */
|
2012-11-11 16:54:26 +00:00
|
|
|
if (BLI_strnlen(loc, 2)) {
|
2018-11-21 12:06:59 +01:00
|
|
|
locales[id] = "";
|
2019-04-22 01:50:49 +10:00
|
|
|
/* Keep this tip in sync with the one in rna_userdef
|
|
|
|
|
* (rna_enum_language_default_items). */
|
2018-11-21 12:06:59 +01:00
|
|
|
locales_menu[idx].description = BLI_strdup(
|
|
|
|
|
"Automatically choose system's defined language "
|
|
|
|
|
"if available, or fall-back to English");
|
2012-10-23 19:39:32 +00:00
|
|
|
}
|
2012-11-11 16:54:26 +00:00
|
|
|
/* Menu "label", not to be stored in locales! */
|
2012-11-02 20:03:15 +00:00
|
|
|
else {
|
2012-11-11 16:54:26 +00:00
|
|
|
locales_menu[idx].description = BLI_strdup("");
|
2012-11-02 20:03:15 +00:00
|
|
|
}
|
|
|
|
|
}
|
2012-11-11 16:54:26 +00:00
|
|
|
else {
|
|
|
|
|
locales[id] = locales_menu[idx].description = BLI_strdup(loc);
|
|
|
|
|
}
|
|
|
|
|
idx++;
|
2012-10-23 19:39:32 +00:00
|
|
|
}
|
2012-10-22 14:04:40 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-10-23 19:39:32 +00:00
|
|
|
line = line->next;
|
|
|
|
|
}
|
2012-10-22 14:04:40 +00:00
|
|
|
}
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-10-22 14:04:40 +00:00
|
|
|
/* Add closing item to menu! */
|
2012-10-23 17:58:46 +00:00
|
|
|
locales_menu[idx].identifier = NULL;
|
2012-10-22 14:04:40 +00:00
|
|
|
locales_menu[idx].value = locales_menu[idx].icon = 0;
|
2012-10-23 17:58:46 +00:00
|
|
|
locales_menu[idx].name = locales_menu[idx].description = "";
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-10-22 14:04:40 +00:00
|
|
|
BLI_file_free_lines(lines);
|
|
|
|
|
}
|
2013-01-21 08:08:20 +00:00
|
|
|
#endif /* WITH_INTERNATIONAL */
|
2012-10-22 14:04:40 +00:00
|
|
|
|
2015-08-16 17:32:01 +10:00
|
|
|
EnumPropertyItem *BLT_lang_RNA_enum_properties(void)
|
2012-10-22 14:04:40 +00:00
|
|
|
{
|
2013-01-21 08:08:20 +00:00
|
|
|
#ifdef WITH_INTERNATIONAL
|
2012-10-22 14:04:40 +00:00
|
|
|
return locales_menu;
|
2013-01-21 08:08:20 +00:00
|
|
|
#else
|
|
|
|
|
return NULL;
|
|
|
|
|
#endif
|
2012-10-22 14:04:40 +00:00
|
|
|
}
|
2009-01-29 05:19:27 +00:00
|
|
|
|
2015-08-16 17:32:01 +10:00
|
|
|
void BLT_lang_init(void)
|
2009-01-29 05:19:27 +00:00
|
|
|
{
|
2013-01-21 08:08:20 +00:00
|
|
|
#ifdef WITH_INTERNATIONAL
|
2014-11-23 15:54:29 +01:00
|
|
|
const char *const messagepath = BKE_appdir_folder_id(BLENDER_DATAFILES, "locale");
|
2015-02-03 17:34:05 +05:00
|
|
|
#endif
|
|
|
|
|
|
2020-08-29 13:41:02 +10:00
|
|
|
/* Make sure LANG is correct and wouldn't cause #std::rumtime_error. */
|
2015-02-03 17:34:05 +05:00
|
|
|
#ifndef _WIN32
|
|
|
|
|
/* TODO(sergey): This code only ensures LANG is set properly, so later when
|
2020-08-29 13:41:02 +10:00
|
|
|
* Cycles will try to use file system API from boost there will be no runtime
|
|
|
|
|
* exception generated by #std::locale() which _requires_ having proper LANG
|
2015-02-03 17:34:05 +05:00
|
|
|
* set in the environment.
|
|
|
|
|
*
|
|
|
|
|
* Ideally we also need to ensure LC_ALL, LC_MESSAGES and others are also
|
|
|
|
|
* set to a proper value, but currently it's not a huge deal and doesn't
|
|
|
|
|
* cause any headache.
|
|
|
|
|
*
|
|
|
|
|
* Would also be good to find nicer way to check if LANG is correct.
|
|
|
|
|
*/
|
2018-09-05 14:31:10 +10:00
|
|
|
const char *lang = BLI_getenv("LANG");
|
2015-02-06 13:54:38 +11:00
|
|
|
if (lang != NULL) {
|
2015-02-03 17:34:05 +05:00
|
|
|
char *old_locale = setlocale(LC_ALL, NULL);
|
2020-08-29 13:41:02 +10:00
|
|
|
/* Make a copy so subsequent #setlocale() doesn't interfere. */
|
2015-02-04 16:02:47 +05:00
|
|
|
old_locale = BLI_strdup(old_locale);
|
2015-02-03 17:34:05 +05:00
|
|
|
if (setlocale(LC_ALL, lang) == NULL) {
|
|
|
|
|
setenv("LANG", "C", 1);
|
|
|
|
|
printf("Warning: Falling back to the standard locale (\"C\")\n");
|
|
|
|
|
}
|
|
|
|
|
setlocale(LC_ALL, old_locale);
|
2015-02-04 16:02:47 +05:00
|
|
|
MEM_freeN(old_locale);
|
2015-02-03 17:34:05 +05:00
|
|
|
}
|
|
|
|
|
#endif
|
UI translation from inside Blender UI: first part.
This commit reshapes a bit runtime button info getter, by adding a new uiButGetStrInfo() which accepts a variable number of uiStringInfo parameters, and tries to fill them with the requested strings, for the given button (label, tip, context, RNA identifier, keymap, etc.). Currently used mostly by existing ui_tooltip_create(), and new UI_OT_edittranslation_init operator.
It also adds a few getters (to get RNA i18n context, and current language iso code).
Finally, it adds to C operators needed for the py ui_translation addon:
*UI_OT_edittranslation_init, which gathers requested data and launch the py operator.
*UI_OT_reloadtranslation, which forces a full reload of the whole UI translation (including rechecking the directory containing mo files).
For the first operator to work, it also adds a new user preferences path: i18n_branches_directory, to point to the /branch part of a bf-translation checkout.
2012-07-09 14:25:35 +00:00
|
|
|
|
2015-02-03 17:34:05 +05:00
|
|
|
#ifdef WITH_INTERNATIONAL
|
2011-10-21 08:16:15 +00:00
|
|
|
if (messagepath) {
|
2012-11-11 16:54:26 +00:00
|
|
|
bl_locale_init(messagepath, TEXT_DOMAIN_NAME);
|
2012-10-22 14:04:40 +00:00
|
|
|
fill_locales();
|
2011-10-21 08:16:15 +00:00
|
|
|
}
|
|
|
|
|
else {
|
|
|
|
|
printf("%s: 'locale' data path for translations not found, continuing\n", __func__);
|
|
|
|
|
}
|
2013-01-21 08:08:20 +00:00
|
|
|
#else
|
|
|
|
|
#endif
|
2009-09-24 07:03:18 +00:00
|
|
|
}
|
2010-07-04 15:35:23 +00:00
|
|
|
|
2015-08-16 17:32:01 +10:00
|
|
|
void BLT_lang_free(void)
|
2012-10-22 14:04:40 +00:00
|
|
|
{
|
2013-01-21 08:08:20 +00:00
|
|
|
#ifdef WITH_INTERNATIONAL
|
2012-10-22 14:04:40 +00:00
|
|
|
free_locales();
|
2013-01-21 08:08:20 +00:00
|
|
|
#else
|
|
|
|
|
#endif
|
2012-10-22 14:04:40 +00:00
|
|
|
}
|
|
|
|
|
|
2013-03-22 14:31:03 +00:00
|
|
|
#ifdef WITH_INTERNATIONAL
|
2020-04-07 13:25:49 -07:00
|
|
|
# define ULANGUAGE \
|
|
|
|
|
((U.language >= ULANGUAGE_AUTO && U.language < num_locales) ? U.language : ULANGUAGE_ENGLISH)
|
2013-03-22 14:31:03 +00:00
|
|
|
# define LOCALE(_id) (locales ? locales[(_id)] : "")
|
|
|
|
|
#endif
|
2013-01-21 08:08:20 +00:00
|
|
|
|
2015-08-16 17:32:01 +10:00
|
|
|
void BLT_lang_set(const char *str)
|
2009-09-24 07:03:18 +00:00
|
|
|
{
|
2013-01-21 08:08:20 +00:00
|
|
|
#ifdef WITH_INTERNATIONAL
|
2012-10-22 14:04:40 +00:00
|
|
|
int ulang = ULANGUAGE;
|
2012-11-11 16:54:26 +00:00
|
|
|
const char *short_locale = str ? str : LOCALE(ulang);
|
|
|
|
|
const char *short_locale_utf8 = NULL;
|
2019-04-17 06:17:24 +02:00
|
|
|
|
2012-11-11 16:54:26 +00:00
|
|
|
/* We want to avoid locales like '.UTF-8'! */
|
|
|
|
|
if (short_locale[0]) {
|
2020-08-29 13:41:02 +10:00
|
|
|
/* Hooray! Encoding needs to be placed *before* variant! */
|
2012-11-11 16:54:26 +00:00
|
|
|
char *variant = strchr(short_locale, '@');
|
|
|
|
|
if (variant) {
|
|
|
|
|
char *locale = BLI_strdupn(short_locale, variant - short_locale);
|
|
|
|
|
short_locale_utf8 = BLI_sprintfN("%s.UTF-8%s", locale, variant);
|
|
|
|
|
MEM_freeN(locale);
|
2011-09-17 20:50:22 +00:00
|
|
|
}
|
2011-12-26 14:52:36 +00:00
|
|
|
else {
|
2012-11-11 16:54:26 +00:00
|
|
|
short_locale_utf8 = BLI_sprintfN("%s.UTF-8", short_locale);
|
2011-09-15 13:20:18 +00:00
|
|
|
}
|
2014-08-05 11:21:02 +09:00
|
|
|
bl_locale_set(short_locale_utf8);
|
|
|
|
|
MEM_freeN((void *)short_locale_utf8);
|
2011-08-31 07:31:02 +00:00
|
|
|
}
|
2012-11-11 16:54:26 +00:00
|
|
|
else {
|
2014-08-05 11:21:02 +09:00
|
|
|
bl_locale_set(short_locale);
|
2012-11-11 16:54:26 +00:00
|
|
|
}
|
2013-01-21 08:08:20 +00:00
|
|
|
#else
|
|
|
|
|
(void)str;
|
|
|
|
|
#endif
|
2016-05-03 12:38:21 +02:00
|
|
|
blt_lang_check_ime_supported();
|
2019-07-29 14:10:54 +02:00
|
|
|
IMB_thumb_clear_translations();
|
2009-01-29 05:19:27 +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
|
|
|
/* Get the current locale (short code, e.g. es_ES). */
|
2015-08-16 17:32:01 +10:00
|
|
|
const char *BLT_lang_get(void)
|
UI translation from inside Blender UI: first part.
This commit reshapes a bit runtime button info getter, by adding a new uiButGetStrInfo() which accepts a variable number of uiStringInfo parameters, and tries to fill them with the requested strings, for the given button (label, tip, context, RNA identifier, keymap, etc.). Currently used mostly by existing ui_tooltip_create(), and new UI_OT_edittranslation_init operator.
It also adds a few getters (to get RNA i18n context, and current language iso code).
Finally, it adds to C operators needed for the py ui_translation addon:
*UI_OT_edittranslation_init, which gathers requested data and launch the py operator.
*UI_OT_reloadtranslation, which forces a full reload of the whole UI translation (including rechecking the directory containing mo files).
For the first operator to work, it also adds a new user preferences path: i18n_branches_directory, to point to the /branch part of a bf-translation checkout.
2012-07-09 14:25:35 +00:00
|
|
|
{
|
2013-01-21 08:08:20 +00:00
|
|
|
#ifdef WITH_INTERNATIONAL
|
2015-08-16 17:32:01 +10:00
|
|
|
if (BLT_translate()) {
|
2015-04-10 15:28:47 +02:00
|
|
|
const char *locale = LOCALE(ULANGUAGE);
|
|
|
|
|
if (locale[0] == '\0') {
|
|
|
|
|
/* Default locale, we have to find which one we are actually using! */
|
|
|
|
|
locale = bl_locale_get();
|
|
|
|
|
}
|
|
|
|
|
return locale;
|
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-04-10 15:28:47 +02:00
|
|
|
return "en_US"; /* Kind of default locale in Blender when no translation enabled. */
|
2013-01-21 08:08:20 +00:00
|
|
|
#else
|
|
|
|
|
return "";
|
|
|
|
|
#endif
|
UI translation from inside Blender UI: first part.
This commit reshapes a bit runtime button info getter, by adding a new uiButGetStrInfo() which accepts a variable number of uiStringInfo parameters, and tries to fill them with the requested strings, for the given button (label, tip, context, RNA identifier, keymap, etc.). Currently used mostly by existing ui_tooltip_create(), and new UI_OT_edittranslation_init operator.
It also adds a few getters (to get RNA i18n context, and current language iso code).
Finally, it adds to C operators needed for the py ui_translation addon:
*UI_OT_edittranslation_init, which gathers requested data and launch the py operator.
*UI_OT_reloadtranslation, which forces a full reload of the whole UI translation (including rechecking the directory containing mo files).
For the first operator to work, it also adds a new user preferences path: i18n_branches_directory, to point to the /branch part of a bf-translation checkout.
2012-07-09 14:25:35 +00:00
|
|
|
}
|
|
|
|
|
|
2012-10-22 14:04:40 +00:00
|
|
|
#undef LOCALE
|
|
|
|
|
#undef ULANGUAGE
|
|
|
|
|
|
2020-08-29 13:41:02 +10:00
|
|
|
/**
|
|
|
|
|
* Get locale's elements (if relevant pointer is not NULL and element actually exists, e.g.
|
2019-04-22 01:50:49 +10:00
|
|
|
* if there is no 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
|
|
|
* *variant and *language_variant will always be NULL).
|
|
|
|
|
* Non-null elements are always MEM_mallocN'ed, it's the caller's responsibility to free them.
|
2020-08-29 13:41:02 +10:00
|
|
|
*
|
|
|
|
|
* \note Keep that one always available, you never know,
|
|
|
|
|
* may become useful even in no #WITH_INTERNATIONAL context.
|
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
|
|
|
void BLT_lang_locale_explode(const char *locale,
|
|
|
|
|
char **language,
|
|
|
|
|
char **country,
|
|
|
|
|
char **variant,
|
|
|
|
|
char **language_country,
|
|
|
|
|
char **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
|
|
|
{
|
|
|
|
|
char *m1, *m2, *_t = 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
|
|
|
m1 = strchr(locale, '_');
|
|
|
|
|
m2 = strchr(locale, '@');
|
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 (language || language_variant) {
|
|
|
|
|
if (m1 || m2) {
|
|
|
|
|
_t = m1 ? BLI_strdupn(locale, m1 - locale) : BLI_strdupn(locale, m2 - locale);
|
2019-04-22 12:20:14 +10:00
|
|
|
if (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
|
|
|
*language = _t;
|
2019-04-22 12:20:14 +10: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
|
|
|
}
|
|
|
|
|
else if (language) {
|
2013-01-21 10:46:01 +00:00
|
|
|
*language = BLI_strdup(locale);
|
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 (country) {
|
2019-04-22 12:20:14 +10:00
|
|
|
if (m1) {
|
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
|
|
|
*country = m2 ? BLI_strdupn(m1 + 1, m2 - (m1 + 1)) : BLI_strdup(m1 + 1);
|
2019-04-22 12:20:14 +10: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
|
|
|
*country = NULL;
|
2019-04-22 12:20:14 +10: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 (variant) {
|
2019-04-22 12:20:14 +10:00
|
|
|
if (m2) {
|
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
|
|
|
*variant = BLI_strdup(m2 + 1);
|
2019-04-22 12:20:14 +10: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
|
|
|
*variant = NULL;
|
2019-04-22 12:20:14 +10: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 (language_country) {
|
2019-04-22 12:20:14 +10:00
|
|
|
if (m1) {
|
2013-01-21 10:46:01 +00:00
|
|
|
*language_country = m2 ? BLI_strdupn(locale, m2 - locale) : BLI_strdup(locale);
|
2019-04-22 12:20:14 +10: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
|
|
|
*language_country = NULL;
|
2019-04-22 12:20:14 +10: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 (language_variant) {
|
2019-04-22 12:20:14 +10:00
|
|
|
if (m2) {
|
2013-01-21 10:46:01 +00:00
|
|
|
*language_variant = m1 ? BLI_strdupcat(_t, m2) : BLI_strdup(locale);
|
2019-04-22 12:20:14 +10: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
|
|
|
*language_variant = NULL;
|
2019-04-22 12:20:14 +10: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 (_t && !language) {
|
|
|
|
|
MEM_freeN(_t);
|
|
|
|
|
}
|
2013-01-21 02:30:40 +00:00
|
|
|
}
|
2016-05-03 12:38:21 +02:00
|
|
|
|
2020-08-29 13:41:02 +10:00
|
|
|
/**
|
|
|
|
|
* Test if the translation context allows IME input - used to
|
2016-05-03 12:38:21 +02:00
|
|
|
* avoid weird character drawing if IME inputs non-ascii chars.
|
|
|
|
|
*/
|
|
|
|
|
static void blt_lang_check_ime_supported(void)
|
|
|
|
|
{
|
|
|
|
|
#ifdef WITH_INPUT_IME
|
|
|
|
|
const char *uilng = BLT_lang_get();
|
2020-11-06 15:29:25 +11:00
|
|
|
ime_is_lang_supported = STR_ELEM(uilng, "zh_CN", "zh_TW", "ja_JP");
|
2016-05-03 12:38:21 +02:00
|
|
|
#else
|
|
|
|
|
ime_is_lang_supported = false;
|
|
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool BLT_lang_is_ime_supported(void)
|
|
|
|
|
{
|
|
|
|
|
#ifdef WITH_INPUT_IME
|
|
|
|
|
return ime_is_lang_supported;
|
|
|
|
|
#else
|
|
|
|
|
return false;
|
|
|
|
|
#endif
|
|
|
|
|
}
|