Automatically Detect the Language of Emails
Robert Ullrich30. May 2018 | Best PracticesConsultingMiscellaneousUse cases
The practical examples presented in our technical blog (blog.otrs.com) 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:
- Go to https://www.detectlanguage.com and register a new account
- Choose a plan. I’m using the “Free” plan for this example
- Note your API key. You can also find it in your Dashboard
OTRS Requirements for this HowTo
- at least OTRS 6.0.x
You need the following OTRS Feature Add-On:
(Adds new invoker for TicketCreate and TicketUpdate in the GenericInterface.)
Third Party Software
You need this third-party software:
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:
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