[Bf-committers] Need some advice about some bug...
lukas.toenne at gmail.com
Fri Feb 8 10:18:35 CET 2013
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)
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
> 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?
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers