[Bf-committers] i18n maintenance is on hold

[Sergey Sharybin]

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
>



-- 
With best regards, Sergey Sharybin