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 an 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

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

#2
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

#1
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 *

This site uses cookies. By continuing to use the site, you agree to the use of cookies. More information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close