[Bf-committers] Need some advice about some bug...

Campbell Barton ideasman42 at gmail.com
Fri Feb 8 10:36:55 CET 2013

On Fri, Feb 8, 2013 at 8:18 PM, Lukas Tönne <lukas.toenne at gmail.com> wrote:
> When using property buttons (layout.prop(...)) the RNA property name
> can always be assumed to be translatable. The label function OTOH has
> no means of distinguishing "raw" text from translatable common terms,
> so it should not make that assumption.
> IMO best way to solve it would be to add a "translate" parameter to
> the label() function:
> label(text="", icon='NONE', icon_value=0, translate=True)

+1, theres probably many places even without UI lists where you
wouldn't want the string translated.

> The default of True ensures that all current label functions work the
> same way they do now and there is no need to update all occurrences.
> Only where a user data string is used should this be set to False to
> avoid unwanted translation. Seems better than adding another
> text/raw_text parameter that would essentially be redundant.
> On Fri, Feb 8, 2013 at 9:48 AM, Bastien Montagne <montagne29 at wanadoo.fr> wrote:
>> Hi Devs,
>> On bf-translations was reported a bug affecting new uilist
>> (http://lists.blender.org/pipermail/bf-translations-dev/2013-February/000284.html).
>> Problem is, when using python RNA UI API, texts (labels) are always
>> translated... And uilists now use py api for their drawing code! So
>> material/vgroups/textures/... names are translated (when a match is
>> found in i18n catalog, of course). No good.
>> I think we need a slight rework of this UI api (best way, if possible,
>> would probably to have a sort of 'wrapper' func that would handle common
>> ui func properties, like 'text' and 'icon'/'icon_value', to handle
>> passing raw text, text to be translated, optional context, etc.).
>> Anyway, we really need more flexibility here (I already proposed
>> something about contexts some weeks ago, but the reviewer did not liked
>> it ;) ). However, it's obviously too late for 2.66!
>> So I wondered what would be best solution, live with this bug in 2.66,
>> or add a nasty (but secure) hack, like adding another 'raw_text' param
>> (that would never be translated!) to the label() function?
>> Cheers,
>> Bastien
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

- Campbell

More information about the Bf-committers mailing list