[Bf-committers] i18n maintenance is on hold

[Ton Roosendaal]

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