| 23 | | |
| 24 | | |
| 25 | | == Committer service == |
| 26 | | |
| 27 | | * ''Status:'' Proposed |
| 28 | | * ''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. |
| 29 | | * ''Contacts:'' Dimitris Glezos |
| 30 | | |
| 31 | | 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. |
| 32 | | |
| 33 | | * Split committer into a different component |
| 34 | | * Move commit code outside transifex/ and into transifex-committer/ |
| 35 | | * 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. |
| 36 | | * Use-cases: projects behind a firewall, upsteam projects not wanting to give SSH access, etc. |
| 37 | | * Work with SELinux a plus. |
| 38 | | |
| 39 | | |
| 40 | | == Server-federated architecture == |
| 41 | | |
| 42 | | * ''Status:'' Proposed |
| 43 | | * ''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. |
| 44 | | * ''Contacts:'' Dimitris Glezos |
| 45 | | |
| 46 | | Example scenario: A Fedora user could submit something to the Debian server, which will wait the approval of a Debian language leader. |
| 47 | | |
| 48 | | * For a single Tx instance to scale well, one might want to split its functionality into (say) el.fooTx.org, pt.fooTx.org, etc. |
| 49 | | * This splitting/joining requires something like a server to server architecture/protocol and the ability to aggregate and delegate stuff on both sides |
| 50 | | * 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. |
| 51 | | * 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. |
| 52 | | |
| 53 | | 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. |
| 54 | | |
| 55 | | 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. |
| 56 | | |
| 57 | | |
| 58 | | == Transifex Mobile App == |
| 59 | | |
| 60 | | * ''Status:'' Proposed |
| 61 | | * ''Summary of idea:'' In this project the student will develop a mobile version of Transifex. The application can be available for one of the three mobile platforms (Android, iPhone or Blackberry). It will be based upon the TX API that needs to be extended. |
| 62 | | * ''Contacts:'' Nikos Tsirakis |
| 63 | | |
| | 79 | |
| | 80 | |
| | 81 | |
| | 82 | |
| | 83 | == Committer service == |
| | 84 | |
| | 85 | * ''Status:'' Proposed |
| | 86 | * ''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. |
| | 87 | * ''Contacts:'' Dimitris Glezos |
| | 88 | |
| | 89 | 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. |
| | 90 | |
| | 91 | * Split committer into a different component |
| | 92 | * Move commit code outside transifex/ and into transifex-committer/ |
| | 93 | * 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. |
| | 94 | * Use-cases: projects behind a firewall, upsteam projects not wanting to give SSH access, etc. |
| | 95 | * Work with SELinux a plus. |
| | 96 | |
| | 97 | |
| | 98 | == Server-federated architecture == |
| | 99 | |
| | 100 | * ''Status:'' Proposed |
| | 101 | * ''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. |
| | 102 | * ''Contacts:'' Dimitris Glezos |
| | 103 | |
| | 104 | Example scenario: A Fedora user could submit something to the Debian server, which will wait the approval of a Debian language leader. |
| | 105 | |
| | 106 | * For a single Tx instance to scale well, one might want to split its functionality into (say) el.fooTx.org, pt.fooTx.org, etc. |
| | 107 | * This splitting/joining requires something like a server to server architecture/protocol and the ability to aggregate and delegate stuff on both sides |
| | 108 | * 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. |
| | 109 | * 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. |
| | 110 | |
| | 111 | 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. |
| | 112 | |
| | 113 | 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. |
| | 114 | |
| | 115 | |
| | 116 | |
