Push Translation Management Tools project to an even more advanced level with a Translation Management server component. This will allow Translators / Translation service providers to use Drupal as a Management system to get translation jobs from other Drupal instances and do the translation work in their own system. With even a small distribution, this product is a few clicks away for end users!
Project page on drupal.org: http://drupal.org/project/tmgmt
Student: Sebastian Siemssen (fubhy)
Mentor: Miro Dietiker (miro_dietiker)
Co-mentor(s): Sascha Grossenbacher (berdir)
This idea has already been discussed in deep detail between fubhy, berdir, miro_dietiker and many other parties. There are amazing responses to the ideas and huge expectations from multilingual users regarding the TMGMT project.
TMGMT has ben initiated in October 2011 and started with a Codesprint in January (25 Developers participated for a week), meanwhile containing >200days of work. Many (paid) translation service providers want to use the system to bring their service into Drupal, three are already integrated and working. The project is working, architecturally robust and clean. The UI / UX needs more love and there are tons of feature requests.
Translation Management Tools solves a ton of issues in Translation Management with Drupal. It allows translators to have a great experience using one interface (onpage) and unifies everything-translatable into the concept of a translation Job that can be passed to a (internal or external) party.
Extend the architecture with a server component. Thus translation management jobs can be passed from a TMGMT client to a TMGMT server and back into the client after job competion.
This server can be used by translators / translation companies to get translation jobs from Drupal installations. They're able to use TMGMT UI to do side-by-side translation of the job and send it back to the client system. All aspects of a translation workflow should be covered in the webservice interface.
As a followup of this base concept amazing features on top of that are possible to improve translation management.
The project schedule will be split up in three major blocks. First, we will have to design and build a sohpisticated underlying API and integrate it with the existing (main) TMGMT project. However, before we can startThe TMGMT Server Component is going to be hosted as a separate project while the TMGMT Client Component will be a Translation Service Plugin and hosted as part of the main TMGMT project.
Now - May 21
Architecture / API discussions and documentation as well as evaluating existing modules (RestWS // Services // Commerce // etc.) for integration in our project. During this period the raw (non-final) architecture will be documented, published, discussed and polished to ease the coding process. During this time we will also reiterate over and polish the core TMGMT module to fill some of the still missing or unfinished parts to prepare it for the integration with the TMGMT Server Component.
May 21 - June 21
Note: This step can't really be split into multiple smaller steps (as of now) as it is so complex because we will be crafting most parts of the APIs / Interfaces during this time. Once all initial discussions are done and the architectural decisions have been made we will be able to provide a more detailed schedule for this period.
Building and testing (simpletest) the underlying APIs (no user interface yet) for the TMGMT Server Component as well as the TMGMT Client Component (Translation Service Plugin). At this point the raw data transfer (back and forth) between the client and server component will be functional. The APIs will work in a way that a Drupal website that runs both components (Server and Client) will also be able to use them internally to handle the translation procedures in one environment (assigning translation jobs to users in the same system instead of sending the translation job to a remote Drupal environment). In order to make this work the interface that handles the communication between the client and the server component will be a pluggable system that potentially supports RestWS (Contrib), Services (Core) and Local (as described) out of the box (extendable).
June 21 - July 2
Adding authentication methods for the communication between the client and the server component. Registered users on a Drupal website that runs the server component will be able to generate API Keys for each Domain that interacts with the server component. The underlying permission system will allow users to act as both, translation providers and translation requesters. Sitebuilders will be able to assign the according rules to user roles and thereby distinguish between (paying) customers and employees / translators that support certain source => target language combinations. Consequently, we will also provide sophisticated permission handling for the server component during this step.
July 2 - July 16
Providing an optional integration for the TMGMT Server Component with Drupal Commerce. Details unknown yet.
July 16 - July 30
Node: This period is estimated to be very short as we will have fully working integration with Views and Rules at this point which will make it fairly simply to create the basic user interface. However, there may always be unpredictable complications.
"Finish" the user interface for the server component (the user interface for the client component are covered by the plugin system that the TMGMT core module already provides).
Note: Parts (a basic version) of the user interface will already be working before we get to this point!
During this time the basic user interface should be fully functional but will definitely need another iterartion to improve the user experience. Due to the extensive integration with Views (contrib) and Rules (contrib) most parts of the user interface will be driven by Views and Views Bulk Operations (in a Drupal Commerce fashion).
August 1 - August 13 / 20
Final tasks / reiteration / testing.
August 20 - August 24
TMGMT Session at DrupalCon Munich with the new features.