L10N migration to transifex.net

noriko noriko at fedoraproject.org
Fri Feb 25 04:21:39 UTC 2011

Stephen John Smoogen さんは書きました:
> 2011/2/24 Karsten Wade <kwade at redhat.com>:
>> Caveat here: I wasn't in any meetings, had no foreknowledge of
>> anything, and am not involved in any of these activities. I'm an
>> observer who just read that IRC log and some mailing list threads over
>> the last few days. I'm going to attempt to keep my reply within the
>> confines of these recent activities and my general knowledge of how to
>> do things the open source way.
>> The IRC log in question:
>> http://meetbot.fedoraproject.org/fedora-meeting/2011-02-15/fedora-meeting.2011-02-15-13.00.log.html
>> On Thu, Feb 24, 2011 at 04:32:37PM +1000, Ruediger Landmann wrote:
>>> I'm a little confused by the nature of the meetings you're talking about
>>> though. I was only at the docs meeting, and that didn't seem to include
>>> any weighing up of options. For that matter, the L10n meeting didn't
>>> either, based on the logs -- it reads to me more like a fait accompli.
>> I think you are right, and there was clearly confusion about the
>> meaning of the vote. My reading is that everyone understood what they
>> were voting for at the end. It was clear people felt it was rushed,
>> uninformed, and risky to proceed. However, the plans do seem to have
>> seen adjustment in response to L10n concerns.
>> I read the results of the L10n meeting as:
>>  Infra: "We really hate to do this, but we have no choice and no time
>>         to do anything other than move all L10n services to Tx.net
>>         immediately. Sorry about the late notice."

Hi Stephen

First of all, I like to express our sincere thanks from our bottom of 
hearts to you and all your team members for every effort and time spent 
for L10n. Now please allow me to ask further help to understand a little 
more the situation where we are standing. It will help to establish an 
exit plan in the future.

> Hmm then I was not communicating very clearly:
> The issue was that transifex has been an ongoing problem for the
> following reasons:
> 1) It is a moving target. Development upstream is fast moving and
> adding new features that translators want.

It seems natural that every software is moving better, adding new 
features. However if a feature newly to be added may interfere existing 
function, as a user translator, I wish not to have a new feature added.

> 2) We are really really behind on upgrades. There have been multiple
> groups who have stepped up, started to do it and then had real life
> hit them with some sort of curve ball. So what started out as 0.7 ->
> 0.8 became 0.7 -> 0.9 and now would have to be 0.7 -> 1.1. We had
> multiple people who for the last 3-4 months have said "We would be
> happy to upgrade, but we aren't really able to do more than that."

I see. So not enough resource can be assigned to such **frequent upgrade 
tasks from long term view.

What I am understanding is that the problems we are encountering are 
caused by older version, and that the solution is to only upgrade. Is 
this correct understanding?
Please let me make the point clear that L10n just wants stable working 
version, not necessarily keep upgraded.

What if we upgrade less often?

> 3) We could have kept the old transifex going but this seemed to cause
> more problems than it solved. There have been many items where people
> were 'hamstrung' with the current software and wanted us to move to
> something new.

The old transifex above means v0.7 or v0.9.1?
Who is 'people' and what 'items' make these people hamstrung?

At least, there were actually v0.9.1 up on the staging server and 
running, which beckerde and lots of people put their time, blood, sweat 
and tears [1]. Many of language teams leaders who put themselves in CC 
had been watching this ticket and hoping/expecting the v0.9.1 system to 
be implemented onto production. What it the cause to make this ticket 

Thanks in advance for your help.


> 4) In looking at Infrastructures current status I realized that we
> were spending a lot of time on triage and not moving forward with
> projects (and in some cases were moving backwards). We looked at what
> our core missions were and what we could have other people do better.
> And it meant pruning back stuff we were not doing well so we could
> focus on getting things done elsewhere.
> Now where we did not hand off things well.
> 1) We asked people in L10N and docs about it but did not make sure
> that was communicated clearly with their groups. That meant we ended
> up with thinking we had agreement but didn't.
> 2) Web software is hard to keep up with unless people stick to it.
> Volunteer infrastructure scales well for certain items but has had
> problems with long term projects. [This is no different than dealing
> with drupal, plone, most Ruby on Rails etc. If your software is
> updating every 3-6 months it is hard to deploy in a production
> environment unless you have dedicated people to keep up with it.]
> 3) As I said in my blog post on this and some other items:
> Now usually after a post like this occurs, we get a bunch of
> volunteers who will say "We can take this over." I am asking people
> not to do this, because frankly volunteering under pressure usually
> means leaving when the pressure is gone. We have gone this route
> several times before, and its not something I think is sustainable.
> We will look for volunteers who can replant the services, document
> them, build out a staging and production service and train OTHER
> volunteers on them so that any replacement service has a chance of
> lasting.

More information about the docs mailing list