Hi Dimitris,

Thanks for your comments.

----- "Dimitris Glezos" <dimi...@glezos.com> wrote:

For the record (since XLIFF is mentioned and since I'm part of the Oasis XLIFF
Technical Committee), I am not aiming to design anything around XLIFF in this
project, other than perhaps support XLIFF is an import/export format for
resources in the same way as we support PO (we do have the odd XLIFF file coming
through for translation). I don't think XLIFF (1.2) is mature enough yet as a
L10N resource format.

I know there are some big ideas in transifex. In fact, when transifex is
mentioned, often people refer to the *goal/idea* of transifex, rather the actual
current implementation. Take for example plugins, transifex doesn't currently
have a plugin system, neither does it have workflow, project management, or any
concept of translation resources internally. Transifex today is a simple 'file
submission system' with a growing community aiming to build it into something
more. With this in mind, 'building on top of transifex' really means redefining
what transifex really is. For example, 'file submission' should really be a
plugin, not a core feature. That means all of transifex today (excluding maybe
the login UI), should really be plugins to a core model of projects, people,
etc, that currently doesn't exist.

Defining this 'model' of a repository doesn't really depend much on the
implementation, and in fact many implementations might help push this faster and
ensure a better solution (if it was on the tx roadmap in the first place). And
it's not like it is impossible for e.g. a java based repository to communicate
with Transifex for file submissions, isn't that exactly what the
remote-interface of TX (on the roadmap) is supposed to provide? What I'm hearing
is "Don't build something new, continue building on the python/tg/transifex
architecture", which is fully understandable. However, considering the cost of
developing this on top of tx (re-architecture, convincing all that it is the
right path to go, immaturity/stability of libraries for e.g. ajax, limited
workflow support), I honestly think it's better with two projects that
'compliment' each other. There are more than enough tasks for everyone in the
existing Tx roadmap, and the idea is bigger than what a combined development team could accomplish. Diversifying and pulling in good people from e.g. the
java-side of things might even help speed things up.

Yes, I know TT very well, and have discussed the library with Dwayne Bailey (the
main visionary behind the project) in the past, even before tx was born. In
fact, a django-migration of Pootle (built on top of the TT) has been on the
agenda for a while, and combining forces with TT is one of the other options I
have been strongly considering for a repository (TT e.g. has a file submission
library, and there is a lot of duplication between tt and tx). Looking at the
svn activity of TT (in my rss reader), it is definetly a project with a
'dangerous' future.

I do understand there is a 'semantic gap' here, and that we do need to provide a
better description and demonstration of why a new project is necessary. I do
believe everything is theoretically possible to build on top of python/tg and
through reuse of concepts in e.g. tx and TT, but I honestly believe if we are
going to manage and drive the development effort in this, it is more worthwhile
to expand beyond the fedora/python community, and use tools that the core
developers would be more comfortable and productive with. This is not a 'we
think you guys should develop this' request, we are taking ownership of the
project, as well as inviting anyone that is interested in the community to
participate and take ownership.

This is *not* about an effort to avoid working with people. It is an effort to
get more people working on this. I know more people in the Java community that
is or might be interested in a open source solution for these problems than in
the Python/Fedora/TG community. And of course adding to this a portion of my
natural bias towards Java, and the fact that the people that would be working on
this would initially be much more productive in Java than in Python (TG2 or
django).

With the fact that we throw this idea out to the fedora/tx community early,
please take that as a sign that we are trying to work with the community, rather
than simply developing something on our own. And I for one will continue being
involved with Tx to some degree, and help out where I can. L10N is an area with
a lot of space for improvement, and an area that has sadly been to some extent
'neglected' except for Dimitris' recent work. We still have a long way to go
before we have what I would call a L10N infrastructure that serves translators
well.

cheers, asgeir