For the purposes of this paper, when reference is made to a ‘language’ it refers to a human spoken/written language and not to a software programming language. Localisation refers to the actions that must be undertaken to ensure that a smartphone application is suitable for each region in which it will be distributed and that it is suitable for end users from different regions and cultures.

The area of localisation is a complex one and an entire project could be devoted to discussing the various methods and technical hurdles associated with this area, such as computer encoded text and alphabets, numerals, writing direction, number formats, date formats, time zones, regulatory compliance etc.. There are many different levels of localisation with different titles. For example, the following titles all refer to localisation in different ways and with different meanings: Localised(L10n), Multilingualised(m17n), Internationalized(i18n) etc.

For the purposes of this project we will focus on the written and spoken language differences from region to region. We will discuss in detail how to prepare n tourist application so that it displays the correct language for the user. As a case study in localisation and language translation, the tourism centre in Bunratty Castle was used. During the sections that follow, references are made to the Bunratty Tourism Centre in Co. Clare. See section 1.3.3 for details.

Manual Language Translation

The historical method, and still the most popular amongst traditional software applications is manual language translation. During this localisation approach, the entire contents of the software application are manually translated using language experts and then this translated content is substituted for the original content of the application. This substitution is done in various ways.

The simplest method is to create and maintain a separate version of the software application for each region. For example, if your application was provided in English, Italian, Chinese, Spanish and Polish, then you would create five distinct applications. Although this is the most straight forward method, it is also the least desirable from the point of view of application maintenance, upgrading and bug fixing. It is impractical to maintain multiple versions of the same software application project, as any change to one version means the same change would have to be made to all language versions of the same application.

To avoid this situation, most smartphone operating systems provide a mechanism to allow the developer to create one version of the software that will allow substitution of the manually translated content in an automatic manner. It is beyond the scope of this project to discuss all the methods in use, however, we will discuss the method used my the main two operating systems, iOS and Android.

To generalise, the following practice is used by most operating systems/development languages: The original text of the application and all the translated text(s) are placed into resource strings which are accessed by the program during runtime. All of these libraries are shipped with the application(or optionally downloaded from a server) and the appropriate library is accessed depending on which language the end user chooses in the Settings section of the application. This approach works well in minimising the changes that have to be made to an application during bug-fixing and upgrading. For example, if there is a problem with a calculation algorithm or the colour of the UI needs to be changed, then only one change needs to be made to the source code. Of course, if a user message needs to be altered, then ALL the language resource files will have to be modified.

Automatic Language Translation

Automatic language translation is a newer approach to localisation.
This involves the ‘on-the-fly’ automatic translation of the native text of an application into a different language. This translation is managed by internal classes or by using 3rd party APIs such as Google’s Translate set of APIs.
During the Bunratty case study, a test application was written in Android to test out the effectiveness of this approach. This application is discussed later in this chapter.
In order to use most 3rd party APIs, the smartphone must maintain a constant connection to the internet, in order to submit the text for translation and to receive the translated text back from the 3rd party server.

This approach has it advantages and disadvantages over traditional Manual translation methods.
The big advantage is that the developer does not have to employ an army of expert linguists in order to translate all the text of an application. This is a big cost saving for the developer. Another advantage is that the developer does not have to maintain a large set of language resource files in order to cater for each language. A third advantage is that the developer can cater for almost every common language spoken(depending on the API used of course). The Google API caters for 50 languages including Irish.

The big disadvantage is that the automatic APIs will never produce a perfect translation, and sometimes will return nothing but gibberish. Again, this is totally dependent of the quality of the API used. However, Google’s API must be considered one of the best available, and even at it’s best, it is always obvious that the translated text was not translated by a native speaker.
There are numerous examples of this provided later during the discussion of the Bunratty site.

Another disadvantage, is that the developer must allow for a slight lag during the translation process. The speed of the translation is dependent on the amount of text being translated, the speed of the internet connection and the speed of the 3rd party server that is carrying out the translation.
Also, the developer must add additional functionality to their software to incorporate the API, and to carry out translations for every string on the user interface and for every text file and piece of information presented to the end user.

Manual Translation using AndroidOS

Android makes things very easy for the developer when designing an application to operate in multiple regions or for end users with different spoken languages.

Provided the developer follows standard Android procedures when writing an application, it can very easily be converted into a multi-lingual application, even if it was not originally designed to do so.

Usually when multiple languages are not an issue and the developer doesn’t envision having to internationalize the application, then you would place the files in the res/values/strings.xml location.
To support both English and other languages, you would create multiple folders, res/values-en and res/values-XX, where the value after the hyphen is the ISO 639-13 two-letter code for the language you want. Your English-language strings would go in res/values-en/strings.xml and the foreign language ones in res/values-XX/strings.xml. Android will choose the proper file based on the user’s device settings.

For example, if you plan to use five languages(as we have done later in this chapter) then you would have the following resource files:
Replace the default res/values/strings.xml with:
res/values-en/strings.xml English
res/values-lt/strings.xml Lithuanian
res/values-ga/strings.xml Irish
res/values-pl/strings.xml Polish
res/values-es/strings.xml Spanish
res/values-sv/strings.xml Swedish

The software developer does not need to provide a special settings screen and does not need to build any additional logic into the application.

The same routine is followed for all the different resources used by your application within the Android development environment. For different Menus for different countries, use the same convention…
Replace the res/menu/abcde.xml with:
res/menu-en/abcde.xml English
res/menu-lt/abcde.xml Lithuanian
res/menu-ga/abcde.xml Irish
res/menu-pl/abcde.xml Polish
res/menu-es/abcde.xml Spanish
res/menu-sv/abcde.xml Swedish

Manual Translation using iOS

Apple also provide a mechanism for localising applications written in iOS.
The same technique is used in the sense that there are separate files for each spoken language. However, the iOS approach is more complicated and laborious than the Android approach.

Nib files(the GUI), icons and images, and static text can all be localised(same as Android).

In a non-localised application, all the Resources reside in the .app directory.
In a localised application, Xcode moves all relevant resources into a separate new directory for each new language supported by your application.
In our example we would have:

en.lproj English
lt.lproj Lithuanian
ga.lproj Irish
pl.lproj Polish
es.lproj Spanish
sv.lproj Swedish

You must inform Xcode that you wish to localise the application. It will not automatically use the localised directories.
To do this you must go into the Properties section of each file that you wish to localise and choose ‘Make File Localizable’ and follow some additional minor steps for each language you wish to use.

The procedure for localising the strings in an application is more cumbersome. You need to run a macro on the original string file in order to generate the new translated string file… you then take this new string file, do the translation on it and copy it back into the application.

Like the Android system, the iPhone will choose the correct languages and settings, based on the Spoken language and locale settings that are on the iPhone OS. No additional coding or setup is required in order to ascertain what language the end user wishes to use.