[openstack-dev] [all] Re-evaluating the suitability of the 6 month release cycle

Tom Fifield tom at openstack.org
Wed Feb 25 04:46:13 UTC 2015


On 24/02/15 19:27, Daniel P. Berrange wrote:
> On Tue, Feb 24, 2015 at 12:05:17PM +0100, Thierry Carrez wrote:
>> Daniel P. Berrange wrote:
>>> [...]

First, Daniel, thank you for the well-written and thought-through post.
I have some comments on translation specifically which I hope can shed
some light on this particular horizontal effort.

With the idea as stated below implemented, I think it would basically
demoralise our translation teams to the point they'd give up. We already
get complaints about people not respecting string freeze as it is :D


> I'm not familiar with how the translations works, but if they are
> waiting until the freeze before starting translation work I'd
> say that is a mistaken approach. Obviously during active dev part
> of the cycle, some translated strings are in flux, so if translation
> was taking place in parallel there could be some wasted effort, but
> I'd expect that to be the minority case. I think the majority of
> translation work can be done in parallel with dev work and the freeze
> time just needs to tie up the small remaining bits.


So, two points:

1) We wouldn't be talking about throwing just a couple of percent of
their work away.

As an example, even without looking at the introduction of new strings
or deleting others, you may not be aware that changing a single word in
a string in the code means that entire string needs to be re-translated.
Even with the extensive translation memory systems we have making
suggestions as best they can, we're talking about very, very significant
amounts of "wasted effort". Something as simple as adding "ing" on a
verb to fix an English grammar mistake means a completely different
sentence in languages I'm familiar with.


2) The overwhelming majority of our [hundreds of] translators are
volunteers.

Unlike many of those writing the software, they are not paid to do what
they do, and do it in their spare time. Make it less fun, and they
simply walk away.



To try and put this in a way that may be more understandable for a
non-translator ... your (impressive!) original email in this thread was
around 3000 words. Translatable strings in horizon is around five times
that at the moment. So imagine that, when writing an email five times
longer than the one you wrote, unpaid, someone you don't really know
that well decided that the section on "the key observations" (230 words
- about 1% of the text of our 'horizon') you just wrote should be
re-arranged - the order of the observations changed, one of them removed
and replaced with another slightly different one, and the conclusion
paragraph wording should be amended to suit.

It would be an understatement to say that such behaviour would be
'annoying' if it happened constantly as you were writing your email.
Consider then if it applied to every email you sought to write :)

Now, the amount of string changes within a release can be left for
someone to work out, but it's certainly a great deal more than a single
percent. Multiply that poor experience by the reality of string change
across all the projects we want to translate. Then multiply it by the
number of languages we want. Finally, multiply it by the number of
people we need to translate a single language. That's a really bad time
for a whole lot of people.


At the moment we're fixing this with string freeze, and that's generally
going pretty well. Right now I don't have a good solution if the strings
in code never stop changing for any period of time, but what has been
proposed above while well-meaning is unfortunately not workable.

We really need to keep our translators as happy as we can. People who
are literate in multiple languages are difficult to find, moreso those
who have technical vocabulary experience in both, and even moreso those
who'll give up their time to help us reach our mission goal of being the
ubiquitous Open Source Cloud Computing platform. We do need them to
achieve it.


Regards,


Tom



More information about the OpenStack-dev mailing list