| | 1 | = Transifex's submissions revisited = |
| | 2 | |
| | 3 | '''proposed by''': Christos Trochalakis ''<yatiohi /at/ ideopolis.gr>'' |
| | 4 | |
| | 5 | == Abstract == |
| | 6 | |
| | 7 | 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 commits them upstream. |
| | 8 | |
| | 9 | 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. |
| | 10 | |
| | 11 | Transifex is now used in production mode in the Fedora Project and is heavily adopted by the Fedora Translators. Although Transifex is a proven and working platform, some architecture limitations seem to arise. |
| | 12 | |
| | 13 | Currently developers receive translations directly at their project's version control system. No other option is available because Transifex's codebase is tied in with a vcs submission style. We want to create an '''abstract submission mechanism'''. On top of that we can build from regular vcs support and email delivery, to generated rss feeds and filing trac and bugzilla tickets. |
| | 14 | |
| | 15 | The submit mechanism will be accessible through json, based on this interface we will build a '''CLI client''', so that translators can send their translations directly from their terminal without using the web interface. |
| | 16 | |
| | 17 | A json-accessible submission will also be the base of a future federated architecture where Transifex web instances can collaborate and send translations to each other. |
| | 18 | |
| | 19 | == The problems with the current architecture == |
| | 20 | |
| | 21 | * A larger set of submit options. A lot of developers don't want to give access to their projects at all, the want to pull translations from Transifex, receive them via email or they want them to be filed as a trac or bugzilla ticket. The current code base doesn't provide the abstractions layers to implement this functionality. |
| | 22 | |
| | 23 | * Translators find the web-based workflow time-consuming. They want to submit easily and quickly through a command-line interface. |
| | 24 | |
| | 25 | * We want a more maintainable code base. Separating the submit mechanism in a different module will help both frontend and backend developers. |
| | 26 | |
| | 27 | * Debugging the version control subsystem can be quite difficult, we have no tests for the current code so the developing procedure runs slowly because we can't test the code easily. |
| | 28 | |
| | 29 | * We want more contributors. Transifex code is not easily extensible. We want to make it easier for new contributors to join us. |
| | 30 | |
| | 31 | == Objectives == |
| | 32 | |
| | 33 | The plan is to build a separate submission module accessible both as a python module (web submissions) and as a web service (json submissions). As a part of that we will write tests that coverage the submission mechanism thoroughly and write extensive documentation for the submission system. |
| | 34 | |
| | 35 | On top of that module: |
| | 36 | |
| | 37 | * We will rebuild the current vcs-specific submissions methods. Also, as a proof-of-concept, we will implement a set of other submission methods. |
| | 38 | |
| | 39 | * We will build a Transifex command line client, so that translators can submit their files through the terminal. |
| | 40 | |
| | 41 | == Goals == |
| | 42 | |
| | 43 | * Submission module accessible as a python module |
| | 44 | |
| | 45 | * Submission module accessible as a web service (json) |
| | 46 | |
| | 47 | * Command line client |
| | 48 | |
| | 49 | * New submission methods |
| | 50 | |
| | 51 | * build in a abstract and extensible way |
| | 52 | |
| | 53 | * 3rd party plugins made easy |
| | 54 | |
| | 55 | === Deliverables === |
| | 56 | |
| | 57 | * A Working instance of Transifex using the new submission system. |
| | 58 | |
| | 59 | * A Working command line client. |
| | 60 | |
| | 61 | === Proposed schedule === |
| | 62 | |
| | 63 | * 15 April - 30 April: Make design decisions, discuss details with the project developers. |
| | 64 | |
| | 65 | * 1 May -30 May: Core functionality |
| | 66 | |
| | 67 | * 1 June - 7 June: First prototype of git commits. |
| | 68 | |
| | 69 | * 8 June - 5 July: Submit mechanism for other vcs. |
| | 70 | |
| | 71 | * 6 July - 30 July: Other submit methods, json support. |
| | 72 | |
| | 73 | * 1 Aug -15 Aug: Command-line Client. |
| | 74 | |
| | 75 | == About me == |
| | 76 | |
| | 77 | My name is Christos Trochalakis and I am an undergraduate student in the Computer Engineering Department at the University of Patras, Greece. I' am actively involved in the Fedora Project, and a member of the Greek Fedora Community. |
| | 78 | |
| | 79 | I have been already developing for Transifex for the past months. During this period Dimitris Glezos (the project maintainer) and I have had the opportunity to discuss the importance of an abstract submission system for Transifex and how to implement it. |
| | 80 | |
| | 81 | I am a web developer and an opensource enthusiast. For the past two years I have dedicated myself to python, Django (a web-framework similar to Turgogears) and git (the well-known distributed VCS). I enjoy Version Control theory and I am familiar with all the version control systems supported by Transifex. |
