Multilingual Drupal - Part 2: Translation Management

In this blog, we’ll further explore a few user stories (introduced in part 1 of this series) and how we resolved their translation needs with the help of the Translation Management (TMGMT) module.

We will see how to:

• Simplify and accelerate the translation process to empower content editors
• Delegate the translation task to a machine and human translation to feed other translation systems (like e.g. Trados or Memsource)
• Prevent data loss or duplication by choosing the content model that fits your expectations, from the beginning
• Identify possible translation processes in a publishing workflow
• Set a deadline, word count, and allow non-Drupal users to receive translation files by mail

These user stories can be grouped into three topics: Content Moderation, Paragraphs translation, and UX experiments. The implementation described below is Drupal 9 ready.

Content moderation

The very basic requirement for a “translation flow” would be to mark the translation as outdated. This is working perfectly fine for non-moderated content, and there is also work in progress in Drupal 9.1 to set this feature back for moderated content.

It could also be a valid use case to set a state for a translation while making use of a publication workflow (e.g. content moderation). So if the source is published, it might not necessarily be the case for the translation.

There is work in progress with TMGMT to support pending revisions and accept translation as a specific moderation state, so this option is available while doing a Job review.

Additionally, we are experimenting with the following features with the TMGMT Content Moderation module:

• Display the current moderation state close to the published status in the content translate form
• Enable translation operation only when the source content reaches a specific state (example: “Published” state)
• Exclude states from the translated entity (example: “For translation” state)
• Redirect on Job completion to the latest revision of the entity

Combined with the Moderation State Columns module, it can also produce this kind of view.

Paragraphs asymmetric translation

Paragraphs can be configured to have asymmetric translations. In this case, the structure from the source entity can differ from the translations. It also allows to not have a translation fallback to the source on the frontend.

Example:

• English source

  • Paragraph text 1 EN
  • Paragraph text 2 EN

• French translation

  • Paragraph text 1 FR

While working with this setup, we need to be aware of several possible issues.

• Data “loss” and dangling references can occur With existing content, switching to and from symmetric to asymmetric can cause data to not appear in the backend or the frontend, and then produce dangling references as the Paragraph entity ID will or will not be the same depending on the chosen setup. So this needs to be taken carefully into account before giving access to the content editors.  

• While using TMGMT, the flow might not be the expected one while doing several translations Let’s continue with our minimal example.  

• For our English source, the first edit is

  • Paragraph text 1 EN
  • Paragraph text 2 EN

• A first French translation Job via TMGMT produces the expected result

  • Paragraph text 1 FR
  • Paragraph text 2 FR

• A second edit of the English source adds a 3rd paragraph, so we have

  • Paragraph text 1 EN
  • Paragraph text 2 EN
  • Paragraph text 3 EN

We translate the same content again with a TMGMT Job: the 3rd paragraph appears in the Job review, but it will never appear on the frontend nor while editing the translation. This is probably not expected. If it is still accepted in the flow, it consumes unnecessary translation resources.

If we manually edit the French translation, to say remove the 2 originally translated paragraphs then add 2 others, we end up with

• Paragraph text 4 FR
• Paragraph text 5 FR

If we translate again the source at this stage, the situation between the TMGMT Job and the frontend will become quite unclear.

• Work in progress We are close to a solution but the integration of TMGMT with Paragraphs asymmetric translation (including content moderation) is still a work in progress.

  • Integration with paragraphs asymmetric translation
  • Translation Problem with Paragraph 1.6 and Paragraphs asymmetric translation widgets

Conclusion: Paragraphs asymmetric integration with TMGMT is feasible but if you plan to translate the content several times/update translations with TMGMT it will most likely not be the right fit for content editors.

UX experiments

A client requested to adapt the TMGMT translation flow for content editors. The assumption was that the Job review will be done right after the translation, so it allowed us to propose a simplification of the UI and skip some steps. A similar request came from another client then we’ve decided to start a proof of concept and gather some of these requirements to see how they could be generalised.

Here are a few examples of alternate flows and simplified UX that could be used by roles that do not need the whole TMGMT stack.

Original TMGMT flow: Machine translation with DeepL

The alternate flows described below are combined with the TMGMT Content Moderation features that were previously mentioned.

Alternate flow 1: Machine translation with DeepL

Once a source reaches the translatable state (Published in this case), the translation occurs in 3 steps: Create the Job > Review the translation > View the result as the Latest revision. The second step could even be skipped by accepting translations without review.

Alternate flow 2: Send a file by mail to a translation service

Here we presume that we can send the XLF file attached.

Combined flow

In some cases, we can also combine the 2 flows and first do a machine translation via e.g. DeepL, and then export the result in the XLF output to populate the initial translation in another translation solution (like Trados or Memsource).

List of other features provided by the Simple TMGMT module:

• Translate with the usual translate operations
• Disable operations links when the user selects multiple languages
• Limit operation links to the supported translators
• Optionally disable translation once already translated (edit only and do not translate again via a Job)
• Per content translation flag to keep track of automatic translation
• Optionally add a delivery date. A default delivery date is calculated based on a certain amount of open days
• Integration with the Swift Mailer module (HTML mail templates with attachments)
• Integration with the Disable Language module (filter languages with permissions)
• If a Job is left as unprocessed allow to continue or delete it via the translation form
• On Job delete or Job item delete, redirect to the entity translation form
• Re-route machine translation error messages to a specific email address (e.g. helpdesk@example.com) and simplify the error messages for content editors

Next steps

• With the deadline, word count, and non-Drupal users in the flow, it opens the door to integration with other information systems and stakeholders. For example, a CRM might contain your translator contact details and translation skills while an accounting platform will get the cost reporting once the translation Job is finished.
• Introduce a generic way to deal with notifications, as suggested in this issue.

If you need help with any of the above including adding translation functionality to your site - get in touch with us today!