[Bf-committers] i18n maintenance is on hold

Sergey Sharybin sergey.vfx at gmail.com
Fri Mar 29 16:01:12 CET 2013 

Guys, please. Stop judging having just shallow vision of how things are
done currently.

It is really almost the same as yours proposals "RNA based IDs", with the
only difference instead of full ID it uses context and original text. (and
this allows to use all that gettext-around features as collaboration tools
for sharing translation tasks and easy merging partial translations form
multiple translators into one file, plus some more tools).

Originally it used RNA only, and the fact it didn't require any further
abstractions around RNA was just nice. Kept RNA code on the same crappiness
level (and yes, i don't consider RNA best ever thing in the world, and it's
pretty limited). And also allowed to handle much more cases where UI
strings vere generating bypassing RNA (for example do you remember how
Editor Type menu is generated? that's fully a tricks of sprintf).

If we'll drop translation contexts from current implementation, bet
there'll be absolutely no differences for blender users in translation made
by all that fancy "RNA id + higher RNA groups blahlbah" and current things.
You just started blaming about thing which was solving corner case of
operator name split into multiple menu levels.

Namely, you could easily translate "Apply Scale" based on both
Context:Operator,Title:Apply Scale and bpy.ops.objects.transform_apply RNA
id. Not a problem at all. But now, when you split this into multiple menus,
like Apply => Scale. You could no longer rely on neither RNA id or
context+operator name. That's just unrelated on any RNA at all.

You'll do have such corner cases in any way you're implementing i18n and
there doesn't seem to be much of places where you need to do tweaks to
improve i18n.



On Fri, Mar 29, 2013 at 4:03 PM, Ton Roosendaal <ton at blender.org> wrote:

> Hi all,
>
> My stance on i8n is this:
>
> - We don't further attempt to put more (loose) strings in i8n control,
> until we have a design in place how to handle such strings well, also for
> non-i8n cases. That is for py as well as C.
>
> - Putting translation hints in py scripts should be not done. Py scripts
> should get simpler instead of more complex.
>
> - Using a translation system based on directly translation of strings was
> not the optimal design decision in first place. It should have been done
> based on the rna-based python syntax for operators and properties to start
> with. (like object.location.x or ops.render_animation, etc).
>
> I really think Bastien and others did a great job sofar on it, and at that
> level we can keep maintaining it. An attempt to push the current system to
> make it "100%" translatable we shouldn't attempt.
>
> My biggest issue with the current system is that we really can do a better
> job on labels, button strings, operator names, tooltips, error messages,
> and so on. Such work shouldn't be breaking every translation attempt we
> have to start with.
>
> -Ton-
>
> ------------------------------------------------------------------------
> Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
>
> On 29 Mar, 2013, at 7: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
> >>
> >
> >
> >
> > --
> > With best regards, Sergey Sharybin
> > _______________________________________________
> > 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
>



-- 
With best regards, Sergey Sharybin

More information about the Bf-committers mailing list