Translation support for additional custom fields in customer requests

[#1]

Language Translation for JSM, ITSM App of the Year Award winner 2021, now translates all user-generated content in a customer request. No matter how many fields are in the request: if the customer generate content, we’ll translate it and display it to agents.

The translations include two types of custom fields:

• Paragraph (richt text)
• Short text (plain text)

This announcement delivers on our promise to enable global multilingual support for companies using JSM. 

It also responds to what customers and partners have repeatedly asked for: customer requests tend to capture additional context, specifications, and instructions in additional fields, and those need to be translated as well. Otherwise, agents have a disjointed experience, with proper translations for only summary and description.

Why Translation for JSM instead of Atlassian Intelligence?

As Atlassian Intelligence continues to get better every month, our translation app is still the best option if you have global customer base. Here’s why:

• No prompting. Issue Translation for JSM translates automatically, without the need for user prompting.
• More efficient. OpenAI’s technology is extremely resource-intensive. It’s more sustainable and fitter to solve translation problems with a specific translation engine.
• Faster. The API calls in our app are solved in a matter of milliseconds, while obtaining a single translation can take up to 25 seconds between prompting and processing. Multiply that by potentially dozens of translations per day, and the wait time starts to get in the way.
• Excellent UX. Issue Translation for JSM removes complexity to both customers and agents, who only need to focus on communicating. Atlassian Intelligence, on the contrary, can only be triggered by agents.

About non-text custom fields

We’re currently not planning to deliver translations for other custom fields, such as dropdown or multi-select fields. A closer look at this request answers why:

• Translating for agents isn’t needed, since custom field values are already in the project default language
• Translating for customers isn’t possible within the data architecture of the customer portal. This requires a bit more of an explanation. Imagine a simple custom field called “location” with two possible values: “on-site” or “remote”. This information should be translated into the customer’s language – that is, to the language in which the request is written. But in order to identify that language, we first need the customer to submit that request – and then it’s too late.

Of course, we’re always eager to understand additional needs. This means that what we don’t plan to do today can be part of our plan for tomorrow or for next year. Reach out if you want to change our mind! 

Workarounds could be possible, for example by forcing a language dropdown. However, we currently don’t think that we’re looking at a trade off end users would be willing to make. Prove me wrong!

[Christiaan Joubert _re_solution_]

Amazing @Jaime Capitel _resolution_ , this is a game changer!