CM policy for for svnbook 1.5 translations

Wed Sep 17 14:18:53 CDT 2008

 - "Ghost reporting"

Although I've been inactive and haven't contributed anything yet, I
would like to comment something that has been bulling me about this,
please read, not only rants believe me.

On Wed, Sep 17, 2008 at 9:57 AM, Jens Seidel <jensseidel at users.sf.net> wrote:
> On Wed, Sep 17, 2008 at 03:36:30PM +0200, Jens M. Felderhoff wrote:
>> The English version of the SVN book 1.5 is finalized and tagged.
>> However, translations are still in progress.
>>
>> Should the translations for 1.5 continue on language-specific branches
>> or should there be a seamless transition to 1.6?

Since its conception, the repository tree has been too English-centric
(I'm talking about branches and tags) which was initially modified
when Grzegorz Adam Hankiewicz contributed patches to provide Spanish
translation of the book web page (which were committed by cmpilato,
@see http://svnbook.red-bean.com/trac/changeset/30 .)

(By the way I'm very proud about having figured out, 'cos I'm an Spaniard too.)

That strategy, to maintain different translations side by side, was
all right for web pages since provides an easy way to provide
localized content in the Apache way, but was overestimated when "the
real" initial import was committed (@see
http://svnbook.red-bean.com/trac/changeset/56 and
http://svnbook.red-bean.com/trac/changeset/57 ,) and was consolidated
when dimentiy started the first translation (@see
http://svnbook.red-bean.com/trac/changeset/275 ,) Norwegian got second
(@see http://svnbook.red-bean.com/trac/changeset/630 ) and Spanish got
third (@see http://svnbook.red-bean.com/trac/changeset/691 .)

Structure was consolidated very soon after (@see
http://svnbook.red-bean.com/trac/changeset/1092 ,) and hasn't changed
since then.

It worked well some time because all that effort was done before
milestone 1.0 (@see http://svnbook.red-bean.com/trac/changeset/1122 ,)
but if you look carefully, you'll find out that some committers were
starting to wonder "against which revision are we working?" (@see
http://svnbook.red-bean.com/trac/changeset/1109 .)

The inability to create branches and tags for translations (it would
have been unnatural to create translation branches and tags inside
main trunk) has lead some translation teams to get distanced more and
more from trunk (I know we can use revision numbers, but is clumsy).
How have the other translation teams worked in this respect?

Another consequence of this is that current tags and branches (from
repository root) have useless snapshots of incomplete translating
efforts that really make no sense. English branches and tags should
had been that, english only.

My point is that if we are looking to maintain translating efforts in
the same way, a reorganization can be really appreciated by us.

And now my own testimony, I'm still holding a "lifetime" (and
modificated) working copy of the Spanish "fake" branch, that I started
almost a year ago and never committed because it could had been
material for milestone 1.1. Why to be worrying about 1.1 if I should
have been behind 1.4 at that time?, because I cannot simply throw away
the effort of my predecessors (to whom by the way I send my
appreciation)  because the structure and the content had changed
considerably, and wanted to finish the 1.1 translation, and "tag it
somewhere". If I had done that, then what?, throw away my own efforts
and go behind trunk?, it would have been better to copy english trunk
again and to start from the very beginning again?, I had no clue and
sadly stopped before beginning (all right there were another reasons
also.)

I didn't shout it loud at that time because there weren't another
reasons to reorganize the repository, winds have changed and it looks
to me that this is a crucial moment to make decisions, although I
don't lean for none of them in a particular way.

First and promising alternative PO files, get_text and the like:

>
> Using PO files it would be trivial to support multiple versions of the
> book. This would of course require more strings to be translated but it
> is no problem of the infrastructure.

Clearly leans to maintain current structure and suggest that a bunch
of localized PO files be maintained side by side, its a cleaner
(although hardly) solution for the current status. The only
restriction that imposes is that Win**** committers doesn't have the
necessary tools to work (correct me if I'm wrong). I had same
limitations with current tools but I got ready them using alternative
tools (Java+Ant+XalanJ and the like).

I've read also that has some limitations that have been noted by
another get_text users in another contexts (like same translation of a
particular string in different context). Forgive me if I'm reluctant:
Has this kind of translation has been done before successfully?, I
mean we are talking about a book, not just some hundreds of localized
strings. I know that someone can be better informed: If you are
reading, can you elaborate?

> That is what I suggested the Russian team yesterday, their translation is
> based on an even older version and updating XML files would be a really
> pain ...

We Spaniards are here sadly, and although we have been silent until
now: "I know we can do much better". Tags and branches could have
helped us to carry out the most difficult thing, planning. And that
leads me to my second point.

I've heard that there is an option to move into Google Code, and I
like the idea because it offers an integrated but lightweight
environment to document, plan, track changes and the like, and the
very best, we translators can be better integrated.

It seems to me an excellent opportunity to relaunch translation
initiatives, and the transition can be a great chance to improve and
clean the infrastructure. Also an opportunity to update tools (or
introduce newer ones).

About leaving Trac, I personally like it, too much I admit (I couldn't
had done previous forensic analysis without it, not that easy,) but
means more administrative burden if you're willing to open some
modules to the public (like tickets and wiki). 0.11.x release
introduces a new and more flexible security model, but increases
administrative burden. SPAM control, if enabled by means of a plugin
(@see http://trac.edgewall.org/wiki/SpamFilter) is annoying sometimes.
In summary, the switch to Google Code means "Obtain less, but work
easily".

We all know to the responsible ones, so feel free to do at your will
(1.5 tag is ready).

That's what I learned, from reading too much and doing nothing.
However, I'm still eager to work in the translation. I just feel like
a writer without paper.

My two cents (and a lot of noise),
----------------------------------------
Johans Marvin Taboada Villca
-`^_^´- .oO(2007-04-24, Kimberly 1 año )
http://softwarelibre.org.bo/jmtaboadav
http://ajayu.memi.umss.edu.bo/jmtaboadav
----------------------------------------