How to work around the "Invalid usage of No-translate" error

When a message is sent for translation and reaches the Unbabel pipeline, we are actually receiving the HTML content the message consists of. Some features such as no-translate rely on correct HTML structure to identify the strings of text that are selected and tell them apart from the remaining text.  As such, there are some scenarios where the HTML of the message content may comprise invalid syntax for the no-translate feature.

Whenever the message contains invalid syntax, an error stating "The message body provided has an invalid usage of non-translatables" will appear above the email composer. A message containing a no-translate syntax error will not generate a translation request.

Below you can find the most common scenarios where errors can appear. Please bear in mind that spotting these problems may be relatively easy, if the change in styling is very evident, or may prove more difficult, depending on how the platform's HTML handles it, and you may wish to try writing the segment from scratch.

• markers have content that is in different HTML levels and have content surrounding them

This is the case whenever opening and closing brackets are formatted differently and have content around them, or are included in different HTML elements for another reason.

ex: This <<< text is not to be translated or >>> is it?

• the HTML is resulting in non-consecutive markers

We need three consecutive brackets, with no HTML between them, in each end to be able to form a valid HTML element. If any of the sequences are interrupted by formatting, for example,  that may not be guaranteed.

ex: This <<<text is not to be translated>>> or is it?

• markers are too deep in the HTML tree

The text may contain a lot of HTML elements preceding and including the no-translate markers. Try closing as many HTML elements as possible and/or isolate the no-translate segment. his includes tables and other graphical representations. For example, you shouldn't have opening brackets inside one row of a table, and closing brackets outside that table.

How to ensure valid syntax

In order to ensure valid syntax when using the no-translate feature and send a translation request successfully, there are some best practices you can follow when writing the brackets:

• avoid formatting the brackets themselves unless the no-translate segment is contained within a portion of the message already formatted like that. You should avoid creating new HTML elements preceding or following the segment.
• be sure to select the full segment if you really need to apply formatting, or leave the brackets out of the selection
• have the brackets surround a block of content which you format separately

ex:

<<<

this is not

to be translated

>>>

Errors caused by Email Templates and Original messages

The chapter above describes the problems arising from a message being written directly in the email composer. However, sometimes the syntax error may lie elsewhere. Two common scenarios include use of Email Templates containing an error that will propagate to all messages using them, and original messages containing the syntax issue.

Email Templates

Templates usually contain tables, images, and other elements that are represented through HTML For the same reasons explained before, this could cause issues with the no-translate feature, especially if the brackets are opened and closed in different elements. Ex:

Title

| <<< Text inside a table row |

| Text inside a table row         |

Image

Signature >>>

In this case, the appropriate construction would be:

Title

| <<< Text inside a table row >>>        |

| <<< Text inside a table row  >>>       |

Image

<<< Signature >>>

Original Messages

Original messages can populate the email composer automatically. These originate from the end user and as such are not subject to control. If they contain brackets configuring invalid syntax (ex: the email client of the end user adds >>> as bullet points), or if these elements are added to the text as part of the translation, they can, individually or in conjunction with the new message, result in invalid syntax. Consider checking your original message for the problem, and removing or editing it  if necessary.