[GSoC Proposal] Translation Management Tools Server

You are viewing a wiki page. You are welcome to join the group and then edit it. Be bold!

Short Description:
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 information

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.

Current status

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.

Project schedule

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.


sounds like a great proposal

Gábor Hojtsy's picture

I've seen a demo of this tool as-is currently. It looks impressive, and the ideas for improvement here look interesting. Drupal lacks good extensible tools in this area and this looks like it could be the "Drupal commerce of Drupal translation" (as in its approach of being extensible and modular and versatile). I think it would be great to see this as a GSoC topic.

This would be great

Jose Reyero's picture

I think this would take Drupal translations to a new level as it sounds like it should be able to handle all kind of translations (interface, content) on a client/server model fully implemented on Drupal. It would be a big help for big organizations having multiple Drupal sites and in-house translation teams.

About TGMT it is a really powerful and full featured tool, and looks like a good model to build upon (I participated on the initial development but it looks like it's getting much bigger and better than that).

I'm wondering whether this would be able to integrate with or maybe eventually replace the current localization server giving us the ability to crowd source translation of drupal.org documentation on the same way we are translating now only hardcoded strings.

So I would love to see this as a GSoC project as it fills some existing need and may be a great help for translations of Drupal content and documentation in the future.

I updated the project

fubhy's picture

I updated the project schedule and provided some details. However, Miro is right in saying that it is hard to provide a fully detailed schedule at this point as this is a really "complex piece of software" (@see http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/fubhy...). The first step, for example, will take more than a month and it doesn't really make sense to split it up as we will have to create all of the APIs and plugin systems in one go before we can proceed with the rest. As soon as the architecture is set and documented (we will do that before we actually start) we will probably be able to provide a more detailed schedule.