On Mon, Sep 15, 2008 at 10:48 PM, "Sankarshan (সঙ্কর্ষণ)"
Asgeir Frimannsson wrote:
> Some of the immediate needs that could be addressed within the existing
> framework (some of which are on the Transifex roadmap) are:
> - Consolidation of Damned Lies and Transifex, allowing retrieving and
> submitting translations through the same interface
> - Allowing retrieving and submitting multiple-files at once (e.g. for
> translating a publican document with many PO files)
> - Simple workflow on top of Transifex (porting features from Vertimus)
> - Better usability and easier user registration process (Fedora specific)
Which ones are not on Tx roadmap ? And, how are those elements proposed
to be met ?
Dimitris is a better person to answer this, but I believe we already have
basic statistics support finished in Transifex upstream. Also, I know Stéphane
Raimbault is involved in integrating the concepts found in Vertimus into
Transifex. What the future regarding integration of Damned Lies concepts such
as Teams and Releases is, I am not sure.
> Looking at the bigger picture, some of the core requirements we
> for Red Hat and community L10N going forward are:
> - Customizable Translation Workflows and integration with e.g. Content
> Authoring Workflows
> - Infrastructure easily adaptable to support new File formats and project
> types (e.g. OpenOffice formats, CMS formats, DTP formats, Wiki, Dita, Java
> formats), rather than relying on 'upstream' projects to fit a certain L10N
> - Managing the life-cycle of a translation project across releases and
> - Translation Reuse and Terminology Management across projects and
> - Job management, scoping, tracking and resourcing
> - Managing and/or Tracking upstream translation projects, pushing changes
Since Tx is gaining traction with other communities as well, is it
prudent to open the net wider and ask about the requirements from such
Yes. I would however add that this project is not directly linked with Tx at
this point. Dimitris has done a great job in networking with other
communities, and have a plan for Tx that goes way beyond Fedora.
> These requirements require a system where the translation
> managed within 'Translation Repositories' (similar to
e.g. Pootle or
> Translations), rather than directly through e.g. upstream
> systems. With a repository-based approach, we would be able to track and
> manage changes to a project on a translation unit level, and manage e.g.
> translation reuse and terminology within and across projects. We could
> retain a link with upstream repositories (like with
> However, this would not be the 'core datamodel', but on
a different layer
> through plug-ins. This link to external repositories could also go beyond
> traditional version control systems, communicating with external sources
> wikis and CMSs.
Does Transifex allow such a set of 'plug-ins' ? If yes, how would one go
about integrating them within the plans of Transifex ? If not, how does
the integration happen ?
The existing Transifex handles very different concepts than what is described
here, and writing this on top of transifex would be hard.
Take for example the 'submission' page, this page is centered around
submitting a file to a repository (or to bugzilla, email as a result of
Christos' SoC work). In a Repository-model, the 'submit' action would be more
about updating the internal state of a project within a repository. To achieve
the same 'workflow' as Transifex, an external plugin could then 'listen'
these changes and transparently submit changes upstream (even by interacting
with Transifex?). In this sense, the project we are proposing could use the
submission logic of Tx, but handle that in the background. There will be
little reuse of actual code from Transifex (most of which is UI-Model
interaction which is linked with file submission).
It is also important to note that the internal format of the repository will
not be PO, but a much richer format more similar to e.g. XLIFF, that
accommodates features such as change tracking and terminology-annotations
within translation units. PO would still be supported as an input format, as
well as an intermediate format that is sent to translators using existing PO
tools. However, in the long term, we aim to provide translators with richer
tools that can make use of the additional meta-data that is part of the
Dimitris mentioned on IRC the other day that the concept of a Translation
Repository similar to e.g. Pootle had been briefly discussed, and could be part
of Transifex in the future. This is exciting news, utilizing Translate Toolkit
more is something that could take Tx to the next level quickly. I think
Transifex with its existing Roadmap serves a very useful purpose, and we are
not trying to 'hijack' that project in any way. In fact, I am also pushing
towards putting more resources into transifex development (read between the
lines whatever you want here).
What we are about to develop is a new way of doing localisation repositories
and workflow, more similar to what happens in many commercial tools than what
we see in open source communities. I feel a bit 'uneasy' about pushing that
onto the Tx roadmap at this stage, and also uneasy about developing such a
'workflow system' in Turbogears.
> We have evaluated a number of existing open source L10N
> systems, but haven't found any (yet) that stands out or satisfies our needs
> requirements as a development platform. Technology-wise, we are
> develop a Java-based(!) system, using technology such as JBoss Seam,
> Hibernate, jBPM and RichFaces. A java based platform will enable us to
> best use of internal expertise in these technologies, as well as
> technology we are developing (as open source) through
> partners in the L10N industry.
Can the results of the evaluation be shared ?
So the alternatives would be Pootle (Translate Toolkit), and Transifex
(Tx+DL+Vertimus), pootle clearly being the more mature from a resource-
management perspective. Pootle works with PO, XLIFF and many other formats.
Still, it is very limited in its use of e.g. workflow support and translation
memory management. One of the main architectural limitations of Translate
Toolkit is it's inheritance hierarchy, where all resource-formats (e.g. PO,
Properties, XLIFF, TMX) inherit from a base resource class. A 'pivot' format
(similar to e.g. XLIFF) with converters to and from the native format is what
we're looking for. Nevertheless, Translate Toolkit (and even Damned Lies) has
a lot of knowledge vested in it in how to handle specific project types
(intltool, gnome-doc-utils, firefox, openoffice). This is reusable across
Feature-wise, it is much more interesting to compare with e.g. Idiom
WorldServer and Lionbridge Freeway, which are commercial solutions in the L10N