Hi S.L,
That's a great example, but you can see that all of them nicely root down to
the actual context via RNA properties or Operators.
Giving translators that 'root' information (the functional api description,
which is static) would provide good quality translations, and allows the
english
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,
This usage of the default context is actually a very good example of
the kind of issues that remain here and there in Blender (again,
probably less than 1% of the whole UI is affected by such stuff, and a
good part of these has already been adressed), so I’m going to explain
it in details.
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
Hi Daniel,
It is not about fixing things that's inside your domain, it was about adding
new concepts for handling translations, which changes how UI scripts have to
maintained.
That topic had two aspects:
- The loose custom strings in UI scripts were there temporary, and meant to
disappear
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
Then i'd say it's high time to solve this loose strings.
This issue is discussing like at least year or two, and nothing changed in
this front meanwhile.
Let's just switch from blaming on things which are here only because old
crap is not fixed to fixing this old crap. That'd be much more
From my translator point of view, explosion of number of strings in POT
files is inevitable. Right now different strings use the same translation
just because we don't want to make code less readable, but make translation
more precise (especially for russiancjk translations). For example here
are
Hi fellow devs and translators,
From now on (at least until the situation has be clarified in one way
or the other), I won't be doing any i18n maintenance anymore, as I was
clearly asked by bl_ui (python ui code) owner to not touch this code
anymore for i18n topics. I do not understand this
On Fri, Mar 29, 2013 at 7:25 AM, Bastien Montagne montagn...@wanadoo.fr wrote:
Hi fellow devs and translators,
From now on (at least until the situation has be clarified in one way
or the other), I won't be doing any i18n maintenance anymore, as I was
clearly asked by bl_ui (python ui code)
Hi guys :)
I have seen some commits today by Bastien, adding various code to python
layout files, especially the text_ctxt parameter. (r55647).
I've seen this for the first time now, although Bastien told me in IRC
that we have this for some weeks. He explained to me why this was added
in IRC.
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
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
On Fri, Mar 29, 2013 at 8:43 AM, Thomas Dinges blen...@dingto.org 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
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.
On Fri, Mar 29, 2013 at 10:13 AM, Thomas Dinges blen...@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
16 matches
Mail list logo
