[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [BOOK] Rules for translation project coordinators

From: Grzegorz Adam Hankiewicz <gradha_at_titanium.sabren.com>
Date: 2004-12-19 21:31:34 CET

On 2004-12-17, kfogel@collab.net wrote:
> > http://svn.collab.net/repos/svn/trunk/doc/translations/spanish/RULES
> I think this document may be of more help to you than to
> other people. It's a lot of process documentation for what is,
> essentially, a simple and straightforward arrangement. I think
> if we handed something like this to other translators, their eyes
> would glaze over, they'd never read it -- yet they'd go ahead
> and get the work done anyway.

There are some issues not done by other translation projects, like
the translation of svnbook.red-bean.com. I personally consider this
a negligence if not done, and the explanation to the fact that I
already have 4 other volunteers for the Spanish project. Enforcing
such simple rules helps the visibility of the project at the cost
of a negligible effort on part of each coordinator. Your (meaning
developers) lack of interest in these issues astonishes me.

Besides, I wouldn't expect suggestions to the chapter related to
the translation community. I expected you would contribute to the
second chapter. Things you could specify:

* Two people are required to have a translation project hosted in
  the main repository. Rules for these people to be available always
  to the Subversion community.

* Write access to the repository doesn't mean a translation project
  can duplicate lots of other files in it, available elsewhere. From
  size optimisation point of view, you could argue the .xcf files of
  the repository are a drag. Gimp handles without problem .xcf.gz
  versions of them, which are on average less than one fourth of
  the space. Not a problem now, but think of scalability.

* r11950 showed that non project members should not write directly
  to the project reserved area, and the following outcry questioned
  my actions and authority. I specified this on the translators
  section, but it wouldn't hurt to say again that the coordinator
  of the translator is capable of making the correct decissions.

* I have received emails where people expressed that I irritate them.
  Well, I'm not here to make friends, but if there is something
  specific I'm doing wrong and you can put in clear words, I'll
  avoid doing it.

* What to do with the people with write access who have lost interest
  in whatever they were working on. Do they lose write access? If
  so, what time period is given?

* Ok, so I'm terribly bad. Subversion development has stalled because
  I flood the mailing list with senseless request and only
  contribute flamewars. What are the things I would have to do for
  the community to want to change me as coordinator? How would this
  take place? Are we talking about some hidden chit-chat on IRC?

* Who is the person in charge of translation projects? Is it still
  Erik Huelsmann? What does he have to do with regards to the
  translation project? Is there anything we (I) have to do as in
  progress reporting?

* Just like my opinion about svnbook.red-bean.com, you could make
  a point that translating the .po files is less work to do than
  translating a full book, and therefore a book translation cannot
  be started until the .po files are done, because every user will
  see those, while not everybody will read the book.

* And another thing would be the translation of the main Subversion
  page. But I expect that this would be so painful for whoever
  admins it that nothing would be done, like the broken mailing
  list archives.

I didn't write those because I was already bored, and thought you
would prefer to write them in proper English.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Dec 19 21:33:08 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.