[Bf-committers] [Bf-blender-cvs] SVN commit: /data/svn/bf-blender [53930] trunk/blender: Python i18n API.

[Bastien Montagne]

Nope, that would not have work, for several reasons (in random order):
* Blender does not use gettext as backend, but boost::locale, which 
handles much more nicely cross-OS locale names (usual Ugly Windows®...).
* Locales are a nightmare to handle when using (dynamic/shared) 
libraries (as they do not always get the same environment as the main 
app using them, tsst...) - and python is usually dynamically linked.
* Translation must not happen at script level, but at (C) RNA/UI level, 
so what you are doing in your addon is bad practice ;).
* Using po's and mo's for each addon would be dramatically complicated 
and heavy (in most cases, there would be just a few tens of msgid's to 
translate) - would mean tens of files for each addon!
* The way it is done currently, script does not have to worry about 
anything (apart from (un)registering its translations).

Note also that the way you are doing it currently, you most probably 
cannot reflect language changes from Blender user settings, not use 
another locale than the default one in the system, as you are 
registering classes (operators & co) with *translated* strings.

As a final word, our message extraction tools will be able to use po's 
as intermediary (i.e. extract messages to po, and then import translated 
po to produce the needed Python tuple code), if the user/coder wants it.

Cheers,
Bastien

On 20/01/2013 19:40, Domino Marama wrote:
> On 01/20/2013 05:29 PM, Bastien Montagne wrote:
>> Revision: 53930
>>            http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=53930
>> Author:   mont29
>> Date:     2013-01-20 17:29:07 +0000 (Sun, 20 Jan 2013)
>> Log Message:
>> -----------
>> 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.).
>>
> Is there any reason this was added rather than just using pythons i18n
> stuff?
>
> I add translation to my (multiple python file) scripts in my primstar
> addon with:
>
> __init__.py
>
> import os
> import gettext
> LOCALE_DIR = os.path.join(os.path.dirname(__file__), 'locale')
> translator = gettext.translation('primstar', LOCALE_DIR, fallback=True)
> _ = translator.gettext
>
> ---->8------
>
> a_script.py
>
> import bpy
> from . import _
>
> class ObjectBakeSculpt(bpy.types.Operator):
>      bl_idname = "object.sculpty_bake"
>      bl_label = _("Bake Sculpt Maps...")
>
> ---->8------ So here the idname is fixed string, label is translatable.
>
> It's then normal po mo stuff for each supported language..
>
> #! /bin/bash
>
> xgettext -LPython -oaddons/primstar/locale/primstar.pot
> --from-code=UTF-8 --copyright-holder='Domino Marama'
> --package-name=Primstar --package-version=2 addons/primstar/*.py
>
> msginit --no-translator -o po/en_GB.po -i
> addons/primstar/locale/primstar.pot
>
> msgfmt -o addons/primstar/locale/en/LC_MESSAGES/primstar.mo po/en_GB.po
>
> So my translators can use all their usual tools for editing the po files..
>
> Just wondering why this commit was added to do something that's already
> possible...
>
> Cheers,
> Domino
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>