Automatically Detect the Language of Emails

Robert Ullrich30. May 2018 | Best PracticesConsultingMiscellaneousUse cases

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 https://www.detectlanguage.com 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

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”:

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

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:

Incoming XSLT mapping:

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:

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

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:

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

More information about the Language Detection API

Please go to the following website, if you need more information: https://detectlanguage.com/documentation

• 2