Mobilizing Mobile for the Worldwide Urban Nomad

By Talia Baruch, Copyous

The Urban Nomad. Sounds super familiar, almost like someone we’ve transformed into, slowly and steadily, encapsulated by the virtual ritual. That’s right; we’re on the GO. And we demand instant, interactive 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, purchase goods or just to slide-flick through our menu bar while we’re trapped in the elevator, trying to avoid the other occupants. By year’s end, smartphones and tablets will have become our principal device, surpassing usage of PC.

Mobile commerce: stand out in the cloud. Mobile web traffic is already surpassing PC-based traffic. According to ABI Research, by 2015 mobile commerce will have reached $119B worth of goods and services purchased via mobile phone. In the less developed world, mobile phones will play a center role in e-commerce, as they are often the only pathway to the internet. This means that companies are now quickly planning their mobile commerce strategy to get a fore and stand out in the cloud within this dominant market. Mobile storefronts now fit into companies’s broader multichannel outreach to consumers. Therefore, when we examine pipeline paths for the localization industry, it is the mobile vertical that waves frantically calling for our attention.

Reaching markup goals. One of the key 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 LSPs need to transition their work scope budgeting to a different ball game model. Typical features in mobile localization are short user interface strings, multiple target language sim-ship releases, focus on layout design, on usability and on compatibility with a variety of platforms: iOS, Android, BlackBerry. Culturalization plays a key role in mobile localization, culturally adapting the usability and design elements to enable a native look & feel for each market.

Tactile tips and tools: Core considerations launching mobile localization. From this point down you can view some of the essentials on the mobile localization to-do list. But first, quick reminder: It’s the strings that interface with the user. If they aren’t localized properly, your entire localization enterprise investment and 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 upfront. Multiply that by the number of target languages and you’re looking at a serious cost creep. Likewise, by maintaining a controlled, concise and consistent source text, we can dramatically reduce translation cost and increase translation quality. We optimize Translation Memory leveraging –increasing high fuzzy matches and ICE matches; we reduce word counts and we avoid ambiguity in translation. 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.”

Internationalization. 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, etc.

Pseudo-localization. Running a pseudo-localization test at project outset saves much time and money during the build testing phase. It verifies that the application is supportive of your target languages and locale requirements: double byte characters for East Asia languages, bi-directional display for Middle Eastern languages, diacritics and accents for Central and Eastern European languages, etc. 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. These specs are most helpful for the translators upfront and dramatically reduce time and cost during the post translation in-context layout testing phase.

Designed for mobile. 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, like “H2″ representing “2nd home phone number.” In most languages it will be impossible to find an equivalent translation for a 2-character word, or even a standard comprehensible abbreviation conveying the same meaning.

User versus system command. In languages where verbs have a feminine and masculine conjugation, like Hebrew for example, it is important to identify whether the UI string command relates to the system – e.g., “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, for example, 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 down side is multiple bugs during functional testing and loss of “personal touch” in the user experience with the hand held.

Fond of font. 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 accents, umlauts and cedillas.

Right to left and vertical text. Right to left 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 use of smart phones in the Arabic market is vastly growing. It is projected to will 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.

Mixed language strings. Brand names typically stay in English. Therefore, strings that incorporate brand names will have mixed English and target language text. For example, for iPhone, brand name terms like “Mobile Me,” “iPhone,” “Apple Store” will remain as is, embedded within the translated words in the same string. For bi-directional 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.

Concatenation. 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 authors’ page. Programmers love to concatenate strings because it allows for cleaner back end support, reducing input of same strings over. 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 target language.

Text expansion. French, Spanish and German expand by 30% from the English. Therefore, 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 very common. Another growing trend triggered by the character space limitation is use of graphics/icons instead of text. This also generates a more international look.

Contextual reference. One of the greatest challenges translators face in mobile localization is receiving isolated context-less UI strings for translation. Sometime 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 — a verb, a noun. Contextual reference is vital! 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. I.e., all UI strings pertaining to the “camera”, “calendar”, “clock” would each get batched separately. Apple and other companies also enable the translators to view a mock of the application for added context within the layout. Needless to mention, developing linguistic assets is mandatory: 1. Glossary of approved key terminology with corresponding definitions and instances in the UI; 2. Style guide defining messaging, voice and formats.

Operability testing. One of the challenges introduced by mobile is the need to test compatibility with different operating systems: iOS, Android, BlackBerry and Windows OS. Another challenge for mobile testing is that 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 localization is into 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/install the software for remote testing.

Content repository. 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.

Collation and sorting. 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 the English.
Target audience. 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.

Affiliate content. Launch ing a mobile localization adventure 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.

Global strategy for new market entry. 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 2nd place trophy. Switzerland is an example for a challenging mobile market, featuring 3 spoken languages: French, German and Italian; 3 dominant operating systems: iOS, BlackBerry and Android; 3 major carriers selling these operating systems: Swisscom, Sunrise and Orange. This translates into a total of 27 test instances, all for one market locale!

It’s the Urban Nomad bit again, for closure. The Early Nomad would travel in search of fresh pasture. The Urban Nomad travels in search of fresh opportunities. His modular, fast pace life style demands multiple adjustments, relocating from one place to another. But all along it is the little lit screen flickering in the back pocket that keeps the humdrum aligned, centralized in cyber space, home away from home.