[Bf-committers] i18n branch (garlic) review

xiangquan xiao xiaoxiangquan at gmail.com
Thu Sep 8 15:26:28 CEST 2011

2011/9/8 Sergey I. Sharybin <g.ulairi at gmail.com>

> Hi,
> Made some code checks and collected all found questions/issues:
> - .Blanguages file is no longer used?
Yes. And nowhere I have found it used when I started working on garlic.

- Unnecessary checks in BLF_gettext. msgid shouldn't be NULL here and
> msgid[0] != '\0' is faster than strlen(msgid)
These checks didn't exist before, but once I got segment fault there because
of NULL pointer. Then the checks was added, and errors gone.

> - In BLF_lang_set(). I think setting locale to smth.UTF-8 should be
> called first. I.e. in my case locale ru_RU doesn't use UTF-8 codepage --
> it uses ISO-8859-5. So i've got errors about invalid utf8 sequences in
> py scripts when setting locale to ru_RU.
It's right. I took a look at the "Battle of Wesnoth", which tries set locale
along with XXX, XXX.UTF-8, XXX.utf-8. So I wrote my code like this.

> - blenfont is added as dependency to all editors..

> - Not sure about UI_GetStyle function. Looks liek something unfinished.
I noticed that U.uistyles is a list of uistyles, but nowhere seems to choose
one based on users' setting. Only in
there is a line saying:
    uiStyle style= *((uiStyle *)U.uistyles.first);    // XXX pass on as arg
We just always use the first style.

In an early version I load unifont as a uistyle after the default one, and
use UI_GetStyle("Unifont") to get it if an utf8 language is in use. If only
Latin characters are used, unifont.ttf will not be loaded. This seems memory

Later I remove this feature, because the language-selection dialog always
needs utf8 fonts. The I just load unifont.ttf as the default uistyle, and
UI_GetStyle() only return the first uistyle as before.

Anyway, in my opinion, UI_GetStyle() is somewhere to get uistyle as users'
wish, especially after font-selection feature added. If so, another field
should also be added to the global UserDef.

> - Numbers+plurals

> - RNA_enum_items_gettexted. Can't it be handles on more lower level?
> - RNA_types_init_gettext. Dislike list of structures, maybe we already
> got list of structs somewhere?
In rna_XXX_gen.c, the properties are actually linked as lists. So I just
played a trick, maybe ugly.

> - WM_read_homefile(). Is it still have to be splitted?
Yes, we still need to do these:
1. read user def
2. init language setting
3. init some UI components
So 1 and 3 are splitted and 2 inserted.

> - Language is changing globally. So there's no way to translate only
> tooltips (like it was in 2.49)
Add another mark, like T_("tooltip")? Switch off other marks( _ and N_ ),
then only tooltips translated.

> Regarding to that _ and N_ macroses. I think it's easy to write operator
> which will ise kinda DFS and collect all strings used by operators and
> RNA. In this case BLF dependency would be avoided for editors and py
> scripts wouldn't be touched. And it can be helpful for case of instant
> language switch (i.e. Dalai told it can be helpful). But it'll need
> gettext stuff called on draw. Not sure how slow it'll be.
I think this is a good idea! Not to disturb too many code and coders is a
wise choice.

> Didn't think much about ways of solving this issues yet, will let you
> know when got new thoughts on this.
> --
> With best regards, Sergey I. Sharybin
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

More information about the Bf-committers mailing list