[Bf-committers] i18n maintenance is on hold

[Bastien Montagne]

This usage of the "default" context is actually a very good example of 
the kind of issues that remain here and there in Blender (again, 
probably less than 1% of the whole UI is affected by such stuff, and a 
good part of these has already been adressed), so I’m going to explain 
it in details.

UILayout.operator() precisely assumes that, when a custom label is 
given, it has to use the "operator" context to translate it. It works 
fine in nearly all cases... But in the "Apply" sub menu, it fails for 
the "Scale" entry: here it is a noun (exactly as other "location" or 
"rotation"), but UI would translate it with "operator" ctxt, and hence 
get a verb. This is not good, since the verb is actually implied by what 
I call "UI context", here the name of the submenu it is embedded in.

Note that this is the only entry of this sub-menu that absolutely 
*needs* to be specified as default context, I set the others the same 
only for sake of consistency (to avoid having dummy things like 
"rotation" with operator ctxt in our translation files), if you think 
it's not worth it it can be reversed with no harm on the "end result".

The same goes for the "modifier_add" & co cases, modifier names are 
defined/translated with default context, so here also we have to 
override the default-for-operators contexts.

Regarding "plural" context, I'm not happy with it either - english is a 
fantastic language for UI itself, but a nightmare for i18n (we should 
use spanish as ref language :p )! I agree this a bit hacky, but if 
someone can explain me how to address a custom label made of a single 
adjective in plural form ("Sharp", implicitly meaning "Sharp Edges"), 
without that kind of tricks, I'd be happy to hear it. :)

On 29/03/2013 07:13, Sergey Sharybin wrote:
> Just two things.
>
> First, why we need to explicitly set text_ctxt=i18n_contexts.default?
> Assuming it by default will remove like most of the changes Thomas
> originally disliked.
>
> Second, when the contexts were introduced, i was hoping not to use contexts
> like "plural" and so. It shall be just "tool", "property" or "default",
> imo. That'd be strange if tool is a noun and property is a verb..
>
> And i don't actually see why you blamed so much on Bastien. Things a re not
> so bad, it's just some smaller crap on top much bigger crap. Don't think
> it's fair to blame on current i18n state because eeh.. Solving it in a
> proper way requires what? Redesigning RNA, adding extra abstraction levels
> on top of RNA or what? That'd be much bigger topic. We need to tackle it
> but as a separate project. Asking to hold some other projects for until
> that's solved is also not so nice idea IMO.
>
> Meanwhile "ultimate RNA system" is cooking, few cleanups will make everyone
> happy i think:
>
> - Avoid explicit specification default context.
> - uiLayout.prop() could have "property" context by default.
> - uiLayout.operator() could have "operator" context by default.
> - uiLayout.label() could have "default" context by default.
>
> I believe it'll separate strings usage well enough and will help keeping
> scripts more clear. Would require moving some translations into contexts,
> but think it could be automated well with a script.
>
>
>
> On Fri, Mar 29, 2013 at 6:14 AM, Campbell Barton<ideasman42 at gmail.com>wrote:
>
>> On Fri, Mar 29, 2013 at 10:13 AM, Thomas Dinges<blender at dingto.org>
>> wrote:
>>> An alternative and also the real solution for the problem would be to
>>> get rid of all (well most of, a few exceptions are fine) custom text
>>> labels. This would eliminate the need for a lot of custom i18 code in
>>> the py UI files.
>>> All those text="" custom strings should be backported to RNA/Operators.
>>> Either by replacing the current UI string in RNA (difficult, as a
>>> property can be used in different contexts / UI places) or add a third
>>> parameter to RNA_def_property_ui_text, like some short_text field or so.
>>>
>>> I know that we discussed such solutions in the past, I can't remember
>>> what the arguments against those were. If someone knows a better
>>> solution, please tell.
>>> I would be willing to work on backporting the custom strings, but we
>>> need a good working solution here first.
>>>
>>> Best regards,
>>> Thomas
>> Removing custom labels in UI has been discussed at length and while
>> its a nice idea I don't think its very practical.
>> Its not at all straightforward how you would go about doing it (lots
>> of operators are single words in a menu/toolbar which wouldn't make
>> sense to name the operator).
>> Unless someone actually plans to go ahead with this and resolve the
>> new problems it raises - I think you can't suggest this as a valid
>> alternative.
>>
>>
>> Checked our UI scripts and this is used in 4 places...
>> space_userpref.py:532:                row.label(text="Translate:",
>> text_ctxt=i18n_contexts.id_windowmanager)
>> space_userpref_keymap.py:83:        row.label(text=km.name,
>> text_ctxt=i18n_contexts.id_windowmanager)
>> space_userpref_keymap.py:114:
>> subcol.operator("wm.keyitem_add", text="Add New",
>> text_ctxt=i18n_contexts.id_windowmanager,
>> space_view3d.py:2546:        col.prop(mesh, "show_edge_sharp",
>> text="Sharp", text_ctxt=i18n_contexts.plural)
>>
>>
>> Other calls pass `i18n_contexts.default`, why does a default value
>> need to be passed at all?
>> properties_physics_common.py:41:
>> sub.operator("object.modifier_remove", text=name,
>> text_ctxt=i18n_contexts.default, icon='X')
>> properties_physics_common.py:46:
>> sub.operator("object.modifier_add", text=name,
>> text_ctxt=i18n_contexts.default, icon=typeicon).type = type
>> properties_physics_common.py:52:        sub.operator(removeop,
>> text=name, text_ctxt=i18n_contexts.default, icon='X')
>> properties_physics_common.py:54:        sub.operator(addop, text=name,
>> text_ctxt=i18n_context.default, icon=typeicon)
>> space_view3d.py:998:        props =
>> layout.operator("object.transform_apply", text="Location",
>> text_ctxt=i18n_contexts.default)
>> space_view3d.py:1001:        props =
>> layout.operator("object.transform_apply", text="Rotation",
>> text_ctxt=i18n_contexts.default)
>> space_view3d.py:1004:        props =
>> layout.operator("object.transform_apply", text="Scale",
>> text_ctxt=i18n_contexts.default)
>> space_view3d.py:1006:        props =
>> layout.operator("object.transform_apply", text="Rotation&  Scale",
>> text_ctxt=i18n_contexts.default)
>> space_view3d.py:1011:
>> layout.operator("object.visual_transform_apply", text="Visual
>> Transform", text_ctxt=i18n_contexts.default)
>> space_view3d.py:1681:
>> text_ctxt=i18n_contexts.default)
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>
>