On Mon, Sep 15, 2008 at 10:48 PM, "Sankarshan (সঙ্কর্ষণ)" <sankarshan.mukhopadhyay@xxxxxxxxx> wrote: > > 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 ? Background: http://groups.google.com/group/transifex- devel/browse_thread/thread/a637310e8ff63555 http://transifex.org/wiki/Development/Roadmap http://transifex.org/roadmap 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 have identified > > 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 > > infrastructure. > > - Managing the life-cycle of a translation project across releases and > > iterations > > - Translation Reuse and Terminology Management across projects and iterations > > - Job management, scoping, tracking and resourcing > > - Managing and/or Tracking upstream translation projects, pushing changes back > > upstream. > > 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 > communities ? 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 lifecycle would be > > managed within 'Translation Repositories' (similar to e.g. Pootle or Launchpad > > Translations), rather than directly through e.g. upstream version control > > 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 still > > retain a link with upstream repositories (like with Transifex/Damned Lies). > > 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 like > > 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' to 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 repository. 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 frameworks and > > systems, but haven't found any (yet) that stands out or satisfies our needs or > > requirements as a development platform. Technology-wise, we are aiming to > > develop a Java-based(!) system, using technology such as JBoss Seam, > > Hibernate, jBPM and RichFaces. A java based platform will enable us to make > > best use of internal expertise in these technologies, as well as making use of > > technology we are developing (as open source) through collaboration with > > 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 solutions. Feature-wise, it is much more interesting to compare with e.g. Idiom WorldServer and Lionbridge Freeway, which are commercial solutions in the L10N space. cheers, asgeir _______________________________________________ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
