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 [email protected] 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 <[email protected]>wrote: > >> On Fri, Mar 29, 2013 at 10:13 AM, Thomas Dinges <[email protected]> >> 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 >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers >> > > > > -- > With best regards, Sergey Sharybin > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
