The urban nomad sounds familiar, almost like someone we’ve transformed into. We’re on the go, and we demand instant information anytime, anywhere. The urban nomad in us is never bound to one place. Wherever we are, across oceans and continents, our carry-on mobile device is our port of communication with the world around us. We pull it out to check our calendar, to interface with our connections, to play games, to purchase goods or just to slide-flick through our menu bar while we’re trapped in the elevator, trying to avoid the other occupants. In 2012, smart phones and tablets will become our principal devices, surpassing the usage of PCs.
Mobile web traffic is already surpassing PC-based traffic. According to ABI Research, by 2015, mobile commerce will have reached $119 billion worth of goods and services purchased via mobile phone. In the less developed world, mobile phones will play a central role in e-commerce, as they are often the only pathway to the internet. This means that companies are quickly planning their mobile commerce strategy to get to the forefront and stand out within this dominant market. Mobile storefronts now fit into companies’ broader multichannel outreach to consumers. Therefore, when we examine pipeline paths for the localization industry, it is the mobile vertical that waves frantically for our attention.
One of the hurdles localization vendors face in the mobile vertical is the conceptual method of budgeting localization accounts. In most other verticals, reaching markup revenue goals is largely determined by word count volumes. In the mobile arena, however, text is minimal, and language service providers (LSPs) need to transition their work scope budgeting to a different ballgame model. Typical features in mobile localization include short user interface (UI) strings; multiple target language (TL) simship releases; focus on layout design; and compatibility with a variety of platforms. Culturalization plays a role in mobile localization, by adapting the usability and design elements to enable a native look and feel for each market. But remember, it’s the strings that interface with the user. If they aren’t localized properly, your entire localization enterprise effort will have been in vain. Our objective is to avoid stop-ship bugs during testing. Therefore, we need to include the developers, UI designers, technical writers and marketers in the frontline internationalization and localization planning during the product development stage. It costs 30 times more to fix internationalization bugs during testing than up front. Multiply that by the number of TLs and you’re looking at a serious cost creep. Steve Jobs once said, “Design is a funny word. Some people think design means how it looks. But of course, if you dig deeper, it’s really how it works.”
Localizing apps
Mobile applications follow the same system internationalization principles we practice for software localization. Highlights are isolating text from code; prepping resource bundles for translation; creating a locale-independent architecture, thereby preserving locale-specifics requirements; and cultural settings. The local API controls the locale formats: date/time/currency and so on.
Running a pseudo-localization test at project outset saves time and money during the build testing phase. It verifies that the application is supportive of your TLs and locale requirements: double-byte characters for East Asian languages; bidirectional display for Middle Eastern languages; and diacritics for Central and Eastern European languages. It is also a helpful process for developers to identify any need for redesign of the UI elements to accommodate for expanded text. Pseudo-localization can also be used to determine the actual character space restriction for different UI strings within the application.
When products are first designed for mobile applications and then transferred to desktop, source text is composed to fit in small screen space and in constrained dialog boxes/buttons. A common issue in those scenarios is when an English source string is a short abbreviation, as in H2, representing “second home phone number.” In most languages it will be impossible to find an equivalent translation for a two-character word, or even a standard comprehensible abbreviation conveying the same meaning. In languages where verbs have a feminine and masculine conjugation, such as Hebrew, it is important to identify whether the UI string command relates to the system — open, close, clear — or to the user. If the command is for the system, the verb will remain in masculine singular form. However, if it addresses the user, the company needs to make a conscientious decision on whether to apply masculine, feminine or both formats. In Hebrew, the feminine verb conjugation is formulated by adding the letter yud to the base masculine format. A company that elects to endorse the politically correct approach and represent both genders would add a back slash followed by the letter yud for every user command in the UI. The downside is multiple bugs during functional testing and loss of “personal touch” in the user experience with the handheld.
Right-to-left text for Arabic, Hebrew, Farsi and Urdu and vertical text for Asian script require a different UI layout. Right-to-left UIs will display image inversion from right to left on the screen. Asian script is double-byte vertical and takes up more screen space, thereby changing the layout displayed in the source English mobile version. Mobile applications with Arabic UI are increasing rapidly as the use of smart phones in the Arabic market is vastly growing. It is projected to have reached 50% of market share by 2015. Most popular mobile devices used in the Arab world today are RIM BlackBerry (50%) and Apple iPhone (30%). The number-one mobile broadband community in the world is Saudi Arabia. That said, most mobile applications today do not support right-to-left text. It is best practice to avoid use of italics or bold font type for digital screens. It affects the readability of special character languages. It is also advised to apply simple interface fonts that support non-Roman characters and enable uncorrupt rendering of special characters, such as fadas in Irish, umlauts in German and cedillas in French.
Brand names typically stay in English. Therefore, strings that incorporate brand names will have mixed English and TL text. For example, brand name terms such as Mobile Me, iPhone and Apple Store will remain as-is, embedded within the translated words in the same string. For bidirectional languages, this introduces multiple bugs during testing. Usually, there’s no issue if the string begins with an English word. However, when an English word appears in the middle of a string in between Hebrew words, for example, we’ll see word inversion issues. Apple developed a tool that identifies problematic strings upfront and flags them for translators at the outset. In many programming languages, string concatenation — joining strings end to end — is a binary infix operator. For example, the string Turn and switch will be concatenated with to the run position. Commonly, name and address strings are joined. The word by is often tied with a name on the author’s page. Programmers love to concatenate strings because it allows for cleaner back-end support, reducing input of the same strings.
English is a language that tolerates concatenation because the word order is predictable. However, in German, for example, word order varies depending on syntax and tense. A verb appears at the end of a sentence in split verb structures. Another language challenging concatenation is Thai where there’s no space between words. Concatenation is localization’s worst enemy. The isolated concatenated strings are translated separately, out of context. Once they’re compiled in the build, they often form messed-up sentence structures in the TL.
French, Spanish and German expand by 30% from the English. Therefore, the localized UI would get truncated in the dialog boxes. Furthermore, unlike English, German is a language that doesn’t tolerate abbreviated nouns, and German nouns can get shamelessly long. These are often truncated on buttons. Hebrew, in contrast, is a language that contracts by 70%-80% from the English. Asian languages have lower character count, but require larger font size for clear readability on the small screen. It is best practice to design large text boxes for the source English UI. Clearly, due to the very small screen size in mobile, text abbreviation is common. Another growing trend triggered by the character space limitation is the use of graphics or icons instead of text. This also generates a more international look.
One of the greatest challenges translators face in mobile localization is receiving isolated, contextless UI strings for translation. Sometimes the resource bundles for translation would have isolated single words representing a command button in the UI. The translators would need to identify what part of speech it is representing, such as a verb or a noun. One of the ways Apple provides contextual reference to the translators is by batching the iPhone source UI application strings for translation per the different feature components. All UI strings pertaining to the camera, calendar or clock would each get batched separately. Apple and other companies also enable the translators to view a mock-up of the application for added context within the layout. Developing linguistic assets is mandatory — a glossary of approved key terminology with corresponding definitions and instances in the UI, and a style guide defining messaging, voice and formats.
Localized content for mobile devices is pre-installed in the client-side devices, whereas some other messages related to services, for example, are routed through a server and hence follow a separate localization workflow. The challenge is to produce error-free localized text embedded into the devices. It is easier to fix bugs in desktop products by simply applying a patch in the next release.
Remember that sorting rules vary even within Roman alphabet languages. Czech, Slovak, Romanian, Polish and Hungarian use Roman characters, but these Central European languages also include characters that do not appear in Western European languages. In Czech, for example, the digraph ch is sorted after h and before i. Accented letters also follow different sorting rules compared with English.
Testing and marketing
Another challenge introduced by mobile is the need to test compatibility with different operating systems: iOS, Android, BlackBerry and Windows OS. Several testing elements need to be performed on the device itself. Software emulators can’t replicate all functional instances or UI screens. When the application’s localization is in multiple languages, it isn’t feasible to send the device to every in-country tester. This is not the case for desktop applications, where in-country testers can download and install the software for remote testing.
Mobile applications target the general public, as opposed to certain software applications or corporate websites that may target industry professionals. Content localization should correspond to the content type and style: more colloquial translations for the former, as opposed to the more formal tone translations appropriate for the latter.
Launching a mobile localization ad-venture doesn’t end with the application localization. There are additional pieces of affiliate content that will consecutively require localization as well: associated marketing copy, application description and localized screenshots for the app store.
When you explore new market opportunities for your application performance, research what types of applications are popular in the target markets. We often customize the application performance, usability and functionality to the locale culture and usability. Another consideration is determining dominant mobile operating systems and carriers in the target markets. For example, China Mobile is the leading carrier in China. In the Arab world, BlackBerry is still the leading device, while Apple iOS takes the second-place trophy. Switzerland is an example for a challenging mobile market, featuring three spoken languages: French, German and Italian; three dominant operating systems: iOS, BlackBerry and Android; and three major carriers selling these operating systems: Swisscom, Sunrise and Orange. This translates into a total of 27 test instances, all for one market locale.
The early nomad would travel in search of fresh pasture. The urban nomad travels in search of fresh opportunities. His or her modular, fast-paced lifestyle demands multiple adjustments in the relocation from one place to another. It is the little lit screen flickering in the back pocket that keeps the humdrum aligned, centralized in cyberspace — the home away from home.
