Transifex Extention System
- Student: NicolasAggelidis
- Mentor: DimitrisGlezos [?]
Abstract
Transifex is a platform that aims in managing the translation processes of open source projects. It is currently in production use by the Fedora Project by hundreds of translators. In order to be used by more communities and manage translations for a more diverse set of projects (like Debian, GNOME, etc) Transifex needs to be able to adapt to new needs and become more scalable. Implementing an extension mechanism for Transifex will help achieve these goals and will enable developers (core and third-party ones) to add capabilities that extend the core functionality with more focused features. For this summer, I propose to implement such an extension system and provide a proof-of-concept extension for Transifex. Detailed Description
Detailed Description
Background
Transifex allows translators to efficiently contribute translations to projects of their choice by eliminating the need of aquiring access privileges to various version contol systems (VCS). The workflow that Transifex provides is as follows. A translator receives a translation file from Transifex or directly from a VCS. She works on the file and then logins in Transifex, which receives the file and commits it directly to the upstream repository.
Transifex can thus be seen as an abstraction layer for the upload procedure. In order to allow a developer to implement custom functionality and extend its capabilities, we must equip Transifex with a powerful plug-in system. This system will "hook" in the download and/or the upload stage, leaving the core application the duties of user login and file uploading. Maybe in the future some developer would like to create his own PO-validator, translation validator, or a plug in that automates the process of uploading a translation and also changing the changelog file of the project.
Objectives
This proposal is concerned with the following two objectives:
1. Refactor part of the code, so that scalability can be improved
2. Implement a plug-in system
I would like to capitalize on the need of Transifex to become more robust, secure and powerful system, in order to accommodate the needs of different communities from all over the world.
Importance
Transifex has received the attention of big open source projects like Fedora, Debian, OpenSuse, and plug-inGNOME among others, which are considering possible installations of it. In Fedora, it is already used by hundreds of translators as the only tool to submit to various upstream projects. By making Transifex more easy to extend and maintain, we invest in increasing the number of people using it.
In addition, since transifex is really good at bridging communities, we may end up bringing the various communities closer to each other. An added bonus of simplifying the translation procedure (without depriving the power that other tools provide) is that small projects can reach out more easily to established translation communities.
Proposed schedule:
May:
- Study the Transifex code, get up to speed with the funcionality, use cases and needs.
- Investigate precisely what type of extensions the project might need from outside developers. Maybe categorize the types of extensions we will support.
- Decide on the set of added capabilities that could be added through a plug in system and which could not.
- End of May: Get in touch with experienced Tx developers and discuss my findings.
June:
- study the plug-in system of other open-source python projects. (7 days)
- Identify projects (Python-based or not) that are known for their good extension system. - Study the way extensions are done in these projects. - Study particularly Python projects - Talk with the Transifex development team and choose on one model
- Ιn particular get in touch with the developing community from projects like mercurial, or turbo gears. (1/2 day)
- Plan the changes, begin refactoring the code, so that it can accommodate the plug in system (7 days)
- Test the project so far, to insure correctness of changes
- Design a sample plug in system as a test unit (7 days)
- End of June : Get in touch with the other developers and agree on the changes that need to be made (1/2 day)
July:
- Begin implementing Tx's plug-in system (15 days)
- Maybe new parameters must be taken into account. Refine initial model.
- Test the new mechanism (10 days)
- Document the extension system (5 days)
August:
- Ιmplement a proof of concept plug-in (15 days)
- Possible plug-in is the "Update Changelog" plug in that will allow translators to bypass the boring stage of updating the change log file, when they make a translation.
- Provide sample documentation on the creation of plug ins
Why me
My name is Nikos Aggelidis and I'm currently a third-year undergraduate student at the Computer Engineering and Informatics department of the University of Patras, Greece. My research interests include Data Structures, Software Engineering, Development Processes, Design Patterns and Code Refactoring.
I am involved in my local LUG (patras-lug.gr), from where I learned about Transifex by its creator Dimitris Glezos at a presentation of his. The fact we live in the same city could be a great plus in my work for this project, since having the main developer as an advisor is the best thing one could hope!
For any questions about myself, my work or my application, please don't hesitate to contact me at n.aggelidis [at] gmail [dot] com.