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 Am 28.03.2013 23:57, schrieb Campbell Barton: > On Fri, Mar 29, 2013 at 8:43 AM, Thomas Dinges <[email protected]> wrote: >> Who said something about "every commit"? ;) >> I talk about bigger changes, and I talk about continuous i18 change >> commits even though I raised objections in the past about that. >> >> Let's not twist the facts here. :) >> >> Am 28.03.2013 22:37, schrieb Daniel Genrich: >>> As far as I know, the devs don't need the "green light" from the module >>> owner for every commit they do. >>> >>> mont29 also did several commits to fluids and cloth, too without running >>> by me first. That was fine, no big changes. >>> I don't think we should encourage "blocking type" commits (everything >>> needs to get "green light" first). We're not Sun with Open Office who >>> scares devs away, right? :-) >>> >>> I was under the impression, that the "module owner" is about bigger >>> things. No idea, I am wrong? ^^ >>> Just my 2 cents. >>> >>> Daniel / Genscher >>> >>> >>> Am 28.03.2013 22:13, schrieb Thomas Dinges: >>>> So all in all, it's all about communication. We have the module owner >>>> list for a reason. Please respect that. >>>> >>>> Best regards, >>>> Thomas >>>> >>>> >>>> >>> _______________________________________________ >>> Bf-committers mailing list >>> [email protected] >>> http://lists.blender.org/mailman/listinfo/bf-committers >> >> -- >> Thomas Dinges >> Blender Developer, Artist and Musician >> >> www.dingto.org > >From what I can tell Bastien is working on his own with translation > code which is no small task and touches > gettext/blenfont/boost/ui/python/rna so I think we should try be > supportive of providing a good API's rather then asking Bastien to > stop. > > Thomas, can you give an alternative you think would be acceptable? > -- Thomas Dinges Blender Developer, Artist and Musician www.dingto.org _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
