= 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 [wiki:Development/SummerCoding 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. == Transifex Mobile App == * ''Status:'' Proposed * ''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. * ''Contacts:'' Nikos Tsirakis * ''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. == Implement "Project Communities" (meta-projects) == Currently Transifex was built to help independent projects manage their translations effectively. Larger projects such as Fedora, GNOME, etc. already have translation teams which manage many projects at once. To allow Transifex to be used effectively by these big-picture meta-projects, a mechanism is needed to "register" smaller projects to them. This way the smaller projects can choose to trust the large ones (communities) and "outsource" all their access control rights to them. This proposal is about creating a high-level permission control mechanism and allow the complete hiding of the permission controls for these projects. == Translation Memory == One of the most often-requested features in Transifex, and any translation tool, is translation memory. Discussions about introducing translation memory (TM) functionality in Transifex have been happening from day 1. From the various conferences the platform was pre- sented, translators have been asking for it to reduce the time they spend translating, and maintainers to improve the quality of their multilingual content. Currently Transifex supports a basic TM functionality: strings to be translated are matched to identical translated strings from the same file of the previous version. Matched strings in this context are separate units of text within a file that can be a word (e.g. a menu item), few words (e.g. a title), a sentence (e.g. a message) or a paragraph containing a number of sentences. Software usually has more sentence or sub-sentence strings while documentation mostly paragraph strings. The main current priority is to improve 100% Matching Capabilities using a Translation Memory and better matching techniques as follows: 1. Create a global product repository (Master Translation Memory) to store all translated strings from previous versions as well as currently finished files in the database. Match strings not only from the same file of the previous version but also from other files of the product past and current in order to increase the number of matched translated strings, reducing the amount of work to be done and improve consistency of the translation. To differentiate between strings there will be an indication as to whether a translation unit is matched to a string of the same file of the previous release or comes from other files of the global TM. 2. Split “paragraph” strings to sentence and “sentence” strings to sub sentence segments if they contain “:” or “tab” for example. Store, search and match strings by their spliced equivalent in order to increase the matches. 3. Fuzzy matching close to 100% can happen to give a boost in close-to-100% matches. Furthermore we aim to introduce Fuzzy Matching (less that 100% match) capabilities to Transifex. 4. Integration of the TM into Lotte, the web editor. A more thorough proposal will be prepared by the prospective students themselves. == Glossary == A Terminology management solution is required to improve consistency between projects and help new members adapt to existing translations. Translators can search to see how terms have been translated. They should be able to add terms, for which language maintainers will get a notification, propose a new translation for a term, and vote for the best ones. This functionality should also be seamlessly embedded in Lotte as well. == Translation prioritization and deadlines == - Allow defining of 'weights' for projects: Some are more important than others, and translators want to know this information. - Take into consideration the number of strings: a 10-string project should be highly prioritized since it's so easy to translate than a 1000-string important one. - Add deadline support for projects, fully integrated with email support, RSS, auto-tweeting etc. Everything should be in place to help developers work efficiently with translators for a development release cycle. == Support for more backend formats == More formats! XLIFF, TS, Ruby files, Java property, .NET. The goal is to find lots of projects using this tool and allow them to get registered on Transifex. == Offline Translation using Lotte == Use something like the Google Gears to support offline editing of translation files. This will allow translators to open up their laptop in the bus or train and translate stuff. When they go online again, the files will be submitted on Transifex. == 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. == Keyboard shortcuts == Transifex has become a very useful tool for translators, and people are spending quite some time on the website (especially in Lotte, the Web editor). Having keyboard shortcuts will help the experience and usability a lot. == Test suite == Transifex needs a more complete test suite. If you're a student who are passionate about detail, figuring out corner-case scenarios, and want to help in one of the most crucial parts of Transifex, do apply.