From Fedora Project Wiki

< ChristosTrochalakis

Revision as of 16:27, 24 May 2008 by Admin (talk | contribs) (1 revision(s))
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

A committer for Transifex

Abstract

Transifex is an upstream-friendly Localization Platform. It acts as a single entry point for submitting translations. Translators login to Transifex and submit their translations, Transifex implements all the low-level vcs-specific stuff and commit them upstream.

Using Transifex, translators interact with the projects in a centralized fashion, all the projects are available through Transifex. This helps both the translators access the projects in a few clicks and each project access a big community of translators. Apart from that, Transifex hides the low-level vcs commands. Translators usually are not technical-skilled people, they they don't and shouldn't need to know 4 or 5 version control system just to submit translations.

Transifex is now used in production mode in the Fedora Project and is heavely adopted by the Fedora Translators. Although Transifex is a proven and working platform, some architecture limitations seem to arise. Currently Transifex runs as a web server, running the actual commits within the same process. We want Transifex to be a light-weighted web application that interacts with many upstream projects scattered all over the web in a distributed fashion. To achieve this, there is the need to decouple the commit proccess from the web application and install committers to various projects.

Transifex Committer will be implemented in Django, a well known Web framework in Python. Transifex will access the committer as a python module or as a web service through json or xml-rpc. Writing a committer will allow us to redesign and refactor VCS support for Transifex.

The problems with the current architecture

  • Big Projects prefer a more distributed nature: Transifex holds SSH keys for the upstream projects for committting. Upstream projects are not willing to give full access to their repositories to downstream projects. They want to host such an application in their own servers to control the submissions. The current way that Transifex works is not easily adopted by large projects.
  • A larger set of commit options. A lot of developers don't want to give access to their projects at all, the want to pull translations from transifex, or receive them via email. The current code base doesn't provide the abstractions layers to implement this functionality.
  • We want a more maintainable code base. Separating the code will help both frontend and backend developers.
  • We want more contributors. Transifex code is not easily extensible. We want to make it easier for new contributors to join the team.

Objectives

The plan is to build a separate committer accessible both as a python module (local committer) and as a web service (remote committer). Transifex will be able to interact with various committers hosted locally or remotely in a per project fashion.

Splitting the committer, will enable upstream projects to install it in their own servers. Once this is done, the Fedora Transifex web application will use the "Fedora committer" for Fedora Projects and the "GNOME committer" for GNOME Projects. Where the "GNOME committer" will acccept translations from both Fedora and Debian Transifex instances.

As a side-effect writing a committer will enable us to redesign and refactor the vcs support in a way that is easely extensible to support alternative requested committ methods such as email or pull functionallity. This will increase the transifex code maintainability and will help contributors to write plugins in a straight-forward and documented fashion.

Goals

  • Service accessible as a python module
  • Service accessible as a web service (json or xml-rpc)
  • build in a decoupled and extendable way
  • 3rd party plugins made easy
  • plain-easy adoption in Transifex code base.

Deliverables

  • A Working proof-of-concept instance of Transifex hooked up with the committer.

Proposed schedule

  • 15 April - 30 April: Make design decisions, discuss details with the project.
  • Request project hosting from Fedora Infrastructure.
  • 1 May -30 May: Core functionality
  • 1 June - 7 June: First prototype of git commits.
  • 8 June - 5 July: Commit mechanism for other vcs.
  • 6 July - 30 July: Json or xml-rpc support.
  • 1 Aug -15 Aug: Modify Transifex to use the committer. Sync with other GSoC projects on Transifex.

About me

My name is Christos Trochalakis and I am an undergraduate student in the Computer Engineering Department at the University of Patras, Greece. I' am involved in the Fedora Project, and a member of the Greek Fedora Community. I have already worked in Transifex with Dimitris Glezos and supplied various patches.

I am a web developer and for the past two years I have dedicated myself to Django, a python web-framework- and git, the vcs system. I enjoy Version Control theory and I am familiar with all the version control systems supported by Transifex.