Software Localisation: Not Easy

1. Why did you enter the software localisation domain?

We are based in Pune and have offi ces elsewhere in India and abroad. One of our founders used to work in HAL, where we routi nely used to encounter Russian text while dealing with aircraft s. At that ti me we realized the need of localizati on and felt that it can be benefi cial to undertake the same in India. We are looking to partner with ISVs so that our product can go with the respecti ve soft ware. There is a big opportunity in India to make sure that people who are not so conversant with English are able to use these products. Plus, there are regulatory requirements to store documents in regional languages for offi cial purposes.

In India there are a wide variety of regional languages but most soft ware used is predominantly English, whereas, if you go to Europe, almost each individual nati on has its own nati onal language but that is followed throughout the vast expanse of the country, which is why most soft ware available today supports a variety of European languages such as French, Polish, German, Italian, etc. In India there are several regional languages but very few localized soft - ware available.

2. Why don't your products support Linux?

We have observed that although in businesses Linux may be widely used on the server, the same is not true for client workstati ons. There are not as many regularly used business applicati ons 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.

3. How do you handle the problem of fragmentation in Android?

We extract resource trees of apps that run on Android and translate them. This way it becomes easier to keep things simple. Not specifi cally talking with respect to mobile, many competi ng soluti ons of ours go deep in the back- end, down to the database level, to build a comprehensive translati on mechanism. However, maintenance becomes a big problem if we take this approach. We do not interfere with the business logic of an applicati on but only the UI, at a layer that immediately precedes actual display of the text on the screen.

4. Do you only display text in the local language? What about input?

We deal only with the output in the form of printi ng, report generati on and on-screen output, not input. The input to our translati on engine has to be in a single language only. We mandate the use of Unicode for output encoding, although the base applicati on is allowed to use ANSI. There arise further issues if we deal with localizati on of input as well. We will need to get into validati on of the input data, which amounts to interference with business logic. When you change the language presented on screen, you need to take care that the translated text fi ts within the boundaries specifi ed for the text box and it is tough to ensure that. There also exist pronunciati on ambiguiti es when you try to output text in most Indian languages from an English source. It becomes a problem to decide what stress needs to be given to vowels, consonants, etc, whose rules are much more specifi c and complex compared to the English alphabet. For instance, if I were using a localized banking soft ware and let's say my name in Devnagari is writt en as विनीत , in English it could be writt en as Vinit, Vineet, or even Veeneet. This makes a lot of diff erence to banking applicati ons. Hence, our approach to translati on is driven by manual parsing of the English text. We do not consider automati c translati on to be a reliable method for using desktop soft ware (especially those used for businesses) although for translati ng websites it may be fi ne and is being used by search engines as well.