Drupal translation workflows with TMGMT

TMGMT builds on Drupal's language system, so it can only translate what Drupal already knows how to translate. Content entities, fields and configuration must be marked as translatable before a job can carry them. Each translation job reads the source entity in its source language and writes the result back as a translation of the same entity, which means the content model decides what can be sent. Confirm during scoping which content types, fields, menus and configuration items must be translatable, and whether any of them are defined in custom code that needs changes. Review the module's own documentation on the Translation Management Tool project page against the Drupal version you run, since the 8.x-1.19 release supports Drupal ^10.3 or ^11.

Yes, but the two systems do not coordinate on their own, so the workflow must be designed on purpose. Content Moderation controls the state of a source or translated revision, such as draft, review or published. TMGMT controls the job that produces the translation. A common design lets a translator deliver a draft translation, a reviewer approve it in a moderation state, and only then does the translation become publishable. Decide which states apply to translations, who may move content between them, and what happens when the source changes while a translation is in review. Confirm this with the TMGMT version and the Content Moderation configuration in your own environment, because state handling for translations needs testing before you rely on it.

Drupal permissions decide who can create jobs, see them, accept returned work and publish the result, and these rights are separate from the rights to edit the source content. A translator account should usually see only the jobs assigned to it, while a project manager can create and track jobs across languages. Editors in one market may need access to content in their language only. Map each role to the TMGMT permissions and to the content permissions on the source node, then test with real accounts. Watch for the case where a user can accept a translation they did not create, since this bypasses review. Ask your team to document the role matrix before build, because permission gaps are hard to see until content is already in the queue.

A search index only returns content it has indexed in the language you query, so translated nodes must be indexed as their own items in the right language. If the index is configured only for the source language, a French visitor may never find a translated page, even though the page exists and renders correctly. Configure the Search API index so translations are included, with language-specific fields and analysis for each supported language. Confirm the index behavior after each translation is published, and check that unpublished or in-review translations are excluded from public results. If you use Solr or another external engine, plan how reindexing runs when a batch of translations is approved, because large batches can take noticeable time to process.

Each translated page needs its own indexable URL, a correct language attribute, and hreflang annotations that link it to the equivalent pages in other languages. Without these, search engines may treat translations as duplicates or show the wrong language to users. URL aliases, the language switcher and the sitemap must all include the translated versions. Ask the SEO owner to confirm the URL structure, whether each language has its own path or domain, and how untranslated items fall back. Test hreflang output after the first published batch, since a missing return link between two pages breaks the pair. Consider this part of the translation scope, not an afterthought, because changing URL structure after launch affects rankings for every language.

TMGMT sends jobs to translators through translator plugins and connectors, which are separate modules that handle the exchange with a human translator, a translation agency or a computer-assisted translation (CAT) tool. Each connector has its own setup, authentication, file formats and status handling, so a service you choose defines much of the integration effort. Confirm which services your organization already contracts with, whether they offer an API or file exchange, and whether a suitable connector exists for your Drupal version. Also confirm where translated content is stored during transit, how credentials are kept, and whether the provider's data processing terms fit your data classification. Verify that the connector is maintained for your Drupal version before you commit to a design.

No. The Translation Management Tool is a contributed module licensed under GPL-2.0-or-later, the same license as Drupal core, so there is no license fee for the module itself. Drupal and its contributed modules have no paid edition. The cost sits in the work around it: planning the workflow, configuring translation jobs and review steps, building or configuring connectors to your translation vendors or translation tools, testing, and keeping the setup working after launch. Translator and vendor fees are a separate line that your translation provider or agency sets under its own contract. Ask any partner to separate module-related work from vendor charges in the quote, and confirm which connector licenses, if any, your chosen translation service requires.

The main drivers are the number of language pairs, the number of content types that must be sent for translation, how many translation services or connectors are involved, and how complex the review and approval path is. Other factors include whether translators work inside Drupal or in an external tool, how much translated content must be checked against source changes, and how much existing content must be backfilled into the workflow. One-time costs cover design, configuration, connector work and testing. Recurring costs cover updates, support and any changes when new languages or vendors are added. Ask for a quote that lists each language pair, connector and review step as separate line items so you can see what each addition costs.

Duration depends mostly on scope, not on the module. A single language pair with one translation service and one review step is a much smaller piece of work than several languages, multiple vendors and a multi-stage approval chain. Other drivers include how many content types are in scope, whether the content model is already clean, the state of your Drupal site, and how quickly your team confirms decisions about job states, review roles and notifications. The timeline should be agreed in the written scope before work starts, with milestones for configuration, connector testing, a pilot with real content and rollout. Ask any partner to show which milestones depend on your team's decisions.

Your team needs to supply four things before the build can finish. First, the list of languages and the locale codes each market needs. Second, named content owners who approve source content, decide what is ready for translation and sign off on translated versions. Third, translator or vendor accounts with the access the connector requires, plus the contact people who handle job questions. Fourth, a decision on who acts as reviewer and who can publish. Engineers will also need a test site, access to the Drupal environments, and a clear rule for how source updates should affect translations already in progress. Missing any of these usually delays testing rather than the code.

Yes, an in-house Drupal team can build a TMGMT workflow if it has the skills to configure contributed modules, manage translation sources and targets, and test job states end to end. The Translation Management Tool builds on Drupal's language system, so a team already comfortable with multilingual Drupal will have the strongest starting point. The main risks are the time needed to learn the module, testing edge cases such as source updates during active jobs, and ongoing ownership once the original builders move on. A partner can be useful for a short scoped engagement, a review of the design, or support after launch. Decide early which parts your team will own and which you want documented for future maintenance.

TMGMT must match the Drupal version your site runs. The current 8.x-1.19 release supports Drupal ^10.3 or ^11, so a site on an older Drupal line will need a different path before TMGMT can be used. Drupal 11 is the current major version, Drupal 12 is scheduled for the week of December 7, 2026, and Drupal 10 reaches end of life on December 9, 2026, according to the core release schedule. Plan a test upgrade of the module, your connectors and your job configuration before each major version. Check the module's compatibility with the target Drupal release, then retest translation jobs and review steps. Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later, so confirm the runtime as well.

Start by deciding what a source change means for work already in progress. Some teams flag the translation as outdated and request a new job, while others allow editors to review changed fields only. The TMGMT project page describes the module's job and translation handling, so have your engineers confirm how the chosen version behaves when a source node is edited during an active job. Build test cases for these scenarios: edits during translation, edits after publication, deleted source content, and new fields added to a content type. Assign an owner for the outdated-translation queue so changes do not sit unnoticed.