Development/SummerCoding/Ideas

Summer Coding Ideas

The following are some ideas which can be used as a base to propose projects for Transifex. For more information on how to apply for them, take a look at the Summer Coding page which talks about Google Summer of Code Program too.

The following list is in no way a complete one. If you have your own idea, get in contact with a member of the core team and propose it right away.

API, CLI and AJAX

  • Status: Proposed
  • Summary of idea: Transifex works well as a server and the website workflow works well with new content providers (eg. translators). Some users find a command-line interface (CLI) more efficient. Implementing an API callable over http will enable a CLI, AJAX calls, and integration with other tools.
  • Contacts: Dimitris Glezos

Notes:

  • Basic idea: Expose most of the website functionality as an API and write a command-line client for it.
  • The API will expose the data as standard objects (eg. JSON).
  • Use the API to implement some AJAX calls in the interface.
  • First step is do it for services not requiring authentication.
  • Authentication will be a tricky part, but there are other similar clients to learn from.
  • Proof-of-concept connectivity with other tools would also be a good addition, to show the added value of the solution.
  • Some of the functionality might be more sensitive, so an API key generation/use mechanism might be needed too, in order to track what client is using the service and how.
  • Finally, logging the API use and generating some statistics might also be a good addition. This can be packaged a separate Django application to be reused by other tools as well.

Extension Engine

  • Status: Proposed
  • Summary of idea: Refactor Transifex's code with hooks (pre, post commit), overridden functions, and classes in order to add a plugin/extension mechanism. Abstract file metaphor, and make support for PO files a plugin and implement a new one for image submissions.
  • Contacts: Diego Búrigo Zacarão

Notes:

  • A more Python-level project, that will need good Python knowledge (read: willingness to learn!)\
  • Very promising, as it will add loads of capabilities for projects adopting Transifex to develop their own tools.
  • It will allow us to have 'contributed' functionality packaged as plugins, which can be tested separately before being merged in the code.
  • Django is already pretty good in separating functionality in applications, and the proposal's core idea would be to allow applications to tweak particular aspects of each other.
  • Part of this proposal will be done as a separate middleware, possibly reused by Django projects other than Transifex.
  • Metrics will be needed to see how good the refactoring was, and what opportunities it will provide -- these metrics would be good to be mentioned in the application itself.

Asynchronous repository support

  • Status: Proposed
  • Summary of idea: Currently Tx requires a constant sync with the remote repo. A submission triggers a push, and pulls happen continuously. We need to add a feature to extend this paradigm with submissions living in Tx, until the next push is run (probably by the developer or an editor).
  • Contacts: Diego Búrigo Zacarão

Notes:

With the successful completion of this idea, we can enable a bunch of nice stuff like, instead of Tx pushing, add support for the developer to pull whenever she needs. Also, having a temporary upload place which needs approval before actually being committed will help QA and get new translators more easily (language leaders can review). These could either be used as a temporary upload space or as a way to allow non-authorized submissions (an authorized user can move a Draft to an actual submission).

Committer service

  • Status: Proposed
  • Summary of idea: Not all upstream repositories like Transifex pushing changesets to it. This idea proposes the implementation of a service run on upstream's own servers which regularly pulls changesets from Transifex and commits them to its own versioning system.
  • Contacts: Dimitris Glezos

Currently Transifex runs as a web server, running the actual commits within the same process. This could be a bit of a security risk, and we'd like to have the commit service run as a different user. An advantage of this is that any repo can run this committer and control the submissions instead of giving SSH access to a downstream project.

  • Split committer into a different component
  • Move commit code outside transifex/ and into transifex-committer/
  • Practically, have it behave as a different application. First, we could communicate with it via an API and then via JSON to have it remotely.
  • Use-cases: projects behind a firewall, upsteam projects not wanting to give SSH access, etc.
  • Work with SELinux a plus.

Server-federated architecture

  • Status: Proposed
  • Summary of idea: One of the most important assets of Tx is its community bridging architecture. When multiple Transifex instances exist, they might want to share stuff, like users, translation statistics and maybe submissions.
  • Contacts: Dimitris Glezos

Example scenario: A Fedora user could submit something to the Debian server, which will wait the approval of a Debian language leader.

  • For a single Tx instance to scale well, one might want to split its functionality into (say) el.fooTx.org, pt.fooTx.org, etc.
  • This splitting/joining requires something like a server to server architecture/protocol and the ability to aggregate and delegate stuff on both sides
  • Some projects might want to have their own Tx instance which contains internal projects, not publicly visible. At the same time, they might have public projects wanting to freely receive translations, but also they might want to allow their internal translators to use this instance as a gateway to all other Tx servers.
  • Minimizing the independence between the scattered Tx instances (ie. building bridges between the Tx "islands") will bring the whole "community bridging" idea of Transifex to a whole new level. This is the goal we want to reach in the long term.

The most important aspect of this idea is architecture design. The student will need to have a very good image of content and translation workflow, the process Transifex adopts, and study how open source projects work together.

Also, most likely the student will want to discuss a lot with the main Transifex developers. Fluent English is probably an important asset for someone applying for this idea.

Queuing System

  • Status: Proposed
  • Summary of idea: Transifex tracks quite a large number of repositories, and serves a number of CPU, Disk and network intensive tasks. This idea proposes the integration of Tx with a high-performance Queuing System such as  AMPQ or Amazon Simple Queuing system.
  • Contacts: Dimitris Glezos

Notes:

  • The use of a Queuing System (QuS) will greatly improve performance, as it will queue tasks to be completed when the servers have cycles available.
  • Will allow the web service to be very responsive by either executing tasks later or outsourcing them on an other server. Users will be forever grateful.
  • Requires some good Python and networking skills.