Automatically Detect the Language of Emails

Robert Ullrich30. May 2018 | Best PracticesConsultingMiscellaneousUse cases


The practical examples presented in our technical blog ( and now in the expert category in our FAQ blog section serve as a source of ideas and documentation to show what is theoretically possible with OTRS in concrete scenarios or sometimes even for more exotic configurations. All configurations presented here were developed under laboratory conditions as a proof of concept. 

We can only guarantee testing and implementation of these concepts to be error-free and productive if implemented in a workshop with one of our OTRS consultants. Without this, the responsibility lies with the customer himself. Please note that configurations from older OTRS versions may not work in the newer ones.

I think everyone of you have asked yourself the question if it’s possible to automatically dispatch tickets into language-specific queues. This might be useful if you have location-based sales departments/support departments a.s.o. So keep on reading, because I want to show you how to build such a “LanguageConnector”. In part 1 of this small blog article series, I want to show you how to set up the web service. If you’re looking for part 2, you can find it here.

Last week I discovered a useful third-party provider, which makes it possible! The name of this provider is “Language Detection API“.

We have some pre-requirements:

  1. Go to and register a new account
  2. Choose a plan. I’m using the “Free” plan for this example
  3. Note your API key. You can also find it in your Dashboard

LanguageConnector Dashboard

OTRS Requirements for this HowTo

OTRS Framework

  • at least OTRS 6.0.x

OTRS Packages

You need the following OTRS Feature Add-On:

  • OTRSTicketInvoker
(Adds new invoker for TicketCreate and TicketUpdate in the GenericInterface.)

Third Party Software

You need this third-party software:

  • XML::Simple
  • XML::LibXML
  • XML::LibXSLT

Configuring the LanguageConnector in OTRS

As always we need a new web service in OTRS. Call it “LanguageConnector”:

LanguageConnector General config

Now we need a new invoker, to send requests to Language Detection:

LanguageConnector Invoker config

As you can see I removed everything, except the article body from my outgoing request data, because I want to keep my payload small.

The next point is the XSLT mapping for our outgoing request and incoming response data:

Outgoing XSLT mapping:

LanguageConnector Invoker XSLT outgoingIncoming XSLT mapping:

LanguageConnector Invoker XSLT incoming

The last point for the invoker is the used event trigger. For testing purposes I’m using “TicketLockUpdate”, but using “TicketCreate” event makes more sense in productive environments:

LanguageConnector Invoker config 1

Next point is to configure the network transport. It’s an easy job:

LanguageConnector transport config

As written in Language Detection API, you can use your API key as username and a password which can be empty or any value.

Let’s continue with our tests.

Testing the LanguageConnector

Depending on your configured event trigger for the invoker, please create a new ticket or (as I’m doing) lock the ticket to yourself. You should now see something similar in the web service debug log:

LanguageConnector debug log

In the ticket history, we can now see that the value was stored in the dynamic field “Language”:

LanguageConnector changed dyn field

More information about the Language Detection API

Please go to the following website, if you need more information:

Robert Ullrich at 06.06.2018, 08:34

Hi Flo! thanks for your feedback! Wait until tomorrow, then I'll release the second part of this "magical thing" ;-) Cheers Robert

Flo at 06.06.2018, 07:04

Oh that is nice! Thanks for this article

Your email address will not be published. Required fields are marked *