Hi all. I'm one of the developers of Transifex. It's great to hear that Maemo
is considering Tx as its L10n platform, since we built Tx with communities
exactly like Maemo in mind.

For the folks who haven't heard of Transifex before, here are a few
introductory links:

LWN.net article
http://lwn.net/Articles/325311/

Overview of Transifex and the challenges of FOSS L10n:
http://blog.transifex.net/2009/03/le...nguages-bloom/

Feature list of Transifex 0.5
http://docs.transifex.org/releases/0.5.html

One of the challenges with Maemo, is that we have content originating from
various sources. Like Linux distributions, translators will like to
contribute to projects that might be hosted internally or externally. Some
developers might host their code/translations on various types of versioning
systems, and some of the UIs might be hosted on the servers of upstream
projects. Transifex was built in a way that developers will have the freedom
to choose the workflow that works best for them (repository location, VCS
type, branching, releasing), while at the same time translators enjoy a
dead-easy interface to find the translation files they'd like to contribute
to.

The platform chosen should support the above and avoid putting an extra burden
of copying translations to the L10n server, possibly losing sync with the
upstream repo, etc. This will only get worse when we have multiple branches
and releases. If we want to also allow folks to contribute directly to the
upstream VCSs, then I wouldn't like to be the guy who is asked to do the
merge. =)

It's also important to note that a lot of the very productive contributors
prefer existing high-efficiency workflows. This includes the use of offline,
desktop tools. This allows them to be more efficient in translating,
run their own toolchain and produce results of better quality. An L10n
platform should compliment and augment this workflow.

From my experience through GNOME and Fedora, translators prefer their desktop
applications for large modules and a Web UI for smaller ones. A powerful
command line interface can lower the barrier to entry and reduce the
necessity for a web UI substancially (`tx get-files italian` and `tx
send-files`). Such a CLI should land in Tx's features in a few months.

Choosing an L10n platform is no easy job. It's an investment, and because it
touches a large number of people (including translators and developers
themselves), a tough one. Here are some of the Transifex features I believe
the Maemo community should note:

- Tx was built ground-up for projects like Maemo. I suspect that most of the
roadmap items will be used right away by the Maemo translators and
developers, so the value will only increase in time.

- Tx was built ground-up as a platform to be adapted, extended, themed, and
integrated with other systems. Continuing qgil's example: Want to edit
a translation from inside an IDE or a desktop app? It should be an
API call away.

- Tx places an emphasis on workflow and collaboration, and aims to capture the
workflow of the whole community (translators, developers, release
engineers). It includes support for real-world mix-matching of translations
in multiple collections, releases, independent projects comprised from
multiple branches potentially hosted in various repos.

- Transifex has a cool name. =)

Kidding aside, some of the other tools mentioned in the thread have been quite
longer than Tx. We've had the chance to study their strong points and avoid
their weaknesses when building Tx. Our team at Indifex was recently formed,
and we're excited to be working in making Tx a full-featured open translation
platform, with which these tools can interoperate if they choose so.

The basic point here is tha Tx is aligned more towards being a L10n platform
rather than a tool to edit translation files from the web. Thinking things
from the architectural side, a web-based PO editor can sit 'on top of'
Transifex and request all the low-level bits from Tx. (read/write files, get
project lists, ACLs, etc).

Here are some of the features the Transifex crew is currently cooking:

- Support for reading translation files from tarballs
- Rich support for teams per project/component/collection/release
- Integration with Bugzilla
- Pluggable simple web-based editor for easy editing of a small number of
strings
- Investigate how Pootle could work _on top of_ Tx. Pootle is extremely good
in supporting translator-specific things like glossary/terminology, memories
etc, and Tx can serve as its 'Virtual Filesystem' and repository management
backend.

And... that's it from me. Whoo, that was long.

Fire away any questions. Or swears for the long post. =)