[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Slides from the Debconf6 2nd BOF about i18n infrastructure


> Be ready that it is now *very likely* that we will go for working with
> the Wordforge people and that it is also *very likely* that the work
> we will expect should be on some part of the needed implementation
> that we have to discuss with Wordforge developers.

If the consensus is that this is the way to go, that's fine with me.
Besides, as far as I can tell, Wordforge people look favourably towards
Python, which is my language of choice, so I can probably be fairly
productive working on Wordforge projects too.

I would like to point out basing the project on Wordforge is a risk
which must be consciously evaluated. With a few days of sketching and
prototyping I can predict fairly accurately how much I can do in X days
working Y hours per day, say, using Zope 3, which I have been working
with for the past two years.  However, I cannot predict how much time
it will take for me to familiarize with Wordforge, how much
faster/slower my rate of development will be in its context, how much
communication with its other developers will affect productivity, how
much time it will take to improve Pootle's performance, etc.  Say, if I
am more than twice slower with the technologies Pootle uses than with
Zope 3 (although this is unlikely), it's almost certainly a net loss for
this project.

In short: I could almost sign my proposal as a formal contract, but it
would be hard to provide guarantees if we use Pootle as the base.
Would you like me to update my proposal to reflect the stronger
relationship with Wordforge?  I don't see much point in doing it
(that document will not significantly affect our future work), but I
feel obliged to ask.

You will notice that I am evaluating strictly the outcome of this
project and not taking into account what Pootle gains from the
cooperation.  This is because the project is already not a small one,
and unnecessarily making it more general will hurt the results.  Of
course, I want to help Pootle succeed as much as anyone, but this must
be a conscious decision.

By the way, I see some positive indicators in Pootle: there are unit
tests, which is always a very good sign.  The coding style is OK too
(although the 2-space indent bugs me a little).  Kid templates are
used for HTML -- these will do fine.  However, it is a bit more
difficult to get a clear picture of the architecture quickly, so I
can't say much about that.

I want to make it clear that I am not a cowboy coder.  Actually, you
can probably already tell that I love discussing things ;) Discussions
are essential so that one knows what he is doing.  On the other hand,
"discussion mode" (particularly "let's discuss!" as opposed to "let's
discuss what to do with X") is different from "getting-things-done
mode", and that's what I had in mind with that comment at the end of my
previous email.

> > I am still not sold on the 'translation owner' idea, I think that
> > would be too rigid.  Of course, this can be made configurable.
> Even though this sounds too strict, I will hereby add that this is
> kind of a mandatory feature. Of course, we will also need all the
> needed mechanisms, including automated ones, to actually *orphan*
> translations when translators are inactive on them.

OK, it is a requirement then.  But I am still not convinced it is a
good idea.  Restrictions are supposed to solve problems and I fail to
see what problem this feature solves that is not addressed by the
ordinary review process.  Could you provide a particular example of
such a problem?

I would suggest to only introduce the requirement when (if) we see
several instances of a problem which would be solved by it.  In that
case, we lose almost nothing.  On the other hand, if the restriction
reduced the translator volume, say, by 70%, this would be a huge loss
and we would never know.

Please don't take this personally, I just want to either assure myself
that this is indeed needed, or to show you that it is not.

> You have been warned. I already told this may sound a bit early for
> people wanting to jump into coding in a very geeky style (small pun,
> no offense intended). You're not alone wanting to jump into code, so
> be sure that things will happen....but talks and discussions HAVE to
> happen. This is what makes long-term viable software.

To be frank, I do not really want to jump into code.  I do know that
in general I tend to talk too much, so I'm trying to compensate ;) As
I have noted in my proposal, I like design, but I don't favour big
design upfront and prefer incremental software evolution and
feedback-based approaches, which is far from "jumping into coding in a
very geeky style".  It's all about eliminating risk.

In comparison, I see an abstract design problem as a theorem, and code
as constructive proof.  The idea is that it is risky to build a huge
system of theorems without at least sketching the proofs.  The proofs
also hint at new theorems that you may not have thought of before.

Obviously the project can't take off at all until we decide if we
want to start from scratch or patch another project.  I suggest that
for the moment we concentrate on this question rather than
interface/permission issues (which will be very important in the near
future, but not right now).  Perhaps someone else could look into
Pootle and share their impressions.

Gintautas Miliauskas

Attachment: signature.asc
Description: PGP signature

Reply to: