Localization of Software is Not an Easy Job

Please brief us about LinguaNext as an SMB.

We are based in Pune although we do have offices elsewhere in India and a few abroad too. We are now about 6 years old and approx 110 strong.

Why was the decision taken to enter into localization? Was it the focus from the beginning?

One of our founders used to work in HAL (Hindustan Aeronautics Limited), where we routinely used to encounter Russian text while dealing with aircrafts. At that time we realized the need of localization and felt that it can be beneficial to undertake the same in India. It does require strong OS fundamentals though.

We are looking to partner with ISVs so that our product can go with the respective software. This is a big opportunity in India to make sure that people who not so conversant with English are able to use the products. Plus, there are increasing regulatory requirements too to store documents in regional languages for official purposes/archival.

It's a different scenario abroad. In India, there are a wide variety of regional languages but most software used is predominantly English, whereas, if you go to Europe for instance, almost each individual nation has it's own national language  that is followed throughout the majority of the country, which is why most software available today supports a vast variety of European languages such as French, Polish, German, Italian, etc. People over there are used to using the software in their own language and are reluctant to use non-native languages, whereas in India there are several regional languages but very few localized software available.

Why doesn't any of your products support Linux?

What we have observed is that although in businesses Linux may be widely used on the server, the same is not true for client workstations. There are not as many regularly used business applications for the Linux desktop as there are for Windows. A couple of clients did approach us with their Linux requirements but currently we do not support Linux systems.

How do you handle the problem of fragmentation in Android?

We extract the resource trees of apps that run on Android and translate them. This way it becomes easier to keep things simple. Not specifically talking with respect to mobile, many competing solutions of ours go deep to the back-end down to the database level to build a comprehensive translation mechanism but then maintenance becomes a big problem if we take that approach. We do not interfere with the business logic of the application but only the UI, at a layer that immediately precedes actual display of the text on the screen.

Do you deal only with displaying text in the localized language or do you handle input as well?

We deal only with the output in the form of printing, report generation and on-screen output, not input. The input to our translation engine has to be in a single language only. So you can say that our products are output-oriented. At the time of deploying the software, there are two methods available, where we give font choices for regional languages to the end user. We mandate the use of Unicode for output encoding, although the base application is allowed to use ANSI.

There arise further issues if we deal with localization of input as well. We need to get into validation of the input data, which amounts to interference with business logic. In fact, localization of output too is not an easy job. When you change the language presented on the screen, you need to take care that the translated text fits within the boundaries specified for the text box and it is tough to ensure that. There also exist pronunciation ambiguities when you try to output text in most Indian languages from an English source. It becomes a problem to decide as to what pressure to give to vowels,consonants, etc., whose rules are much more specific and complex compared to the English alphabet. For instance, if I were using a localized banking software and let's say my name in Devnagari is written as विनीत, in English it might have been written as any of Vinit, Vineet, Veeneet, etc. This makes a lot of difference to banking applications.

Hence, our approach to translation is driven by manual parsing of the English text. We do not consider automatic translation to be a reliable method for using desktop software (especially those used for business) although for translating websites it may be fine enough and is being used by search engines too.

Let's say I have a PDF file with handwritten English contents. Can your software perform an OCR on the same and translate it to regional language?

No.