Phasing Software i18n and L10n: What’s Right for Your Company?

Going global is a big step. Moving from the massive challenge of getting a company off the ground and past the initial challenge of proving that your idea can work has already put your company in a league beyond most.

Aside from incidental web traffic and interest from new countries and regions, for many companies, going global means setting up partnerships, offices and agents. For software, it also means internationalizing and localizing software so that it’s competitive and meets sales requirements. Internationalization (i18n) of your software is a business case driven undertaking, in response to opportunities and strategy. It is not like a feature that you might add in a sprint or two.

That said, all global targets are not equal in terms of technical requirements. This post gives you a brief overview of stages of software i18n and localization (L10n) and what opportunities each may open for your company. It’s not intended as a technical resource, but more as a primer for product and localization managers.

The Basics

Venice, Italy

  • Internationalization, often abbreviated as i18n (i – then 18 letters – n), is the process of making a single code base locale-independent so the application can be easily localized to other locales with no source code changes.
  • Localization, often abbreviated as L10n (L– then 10 letters– n), is the translation and application of locale-specific terms and style so that a product is locale-specific – that is, it looks and reads like a product native to the market in which it is being sold.
  • Globalization, sometimes abbreviated as g11n (g– then 11 letters– n), includes both internationalization and localization together and often refers to the entire process of supporting other locales.
  • A locale in computing is a set of parameters that defines the user’s language, region and any special variant preferences that the user wants to see in their user interface. Usually a locale identifier consists of at least a language identifier and a region identifier. Consider that in both the US and the UK, the typical language is English, but other parameters such as date format, temperature and even some spelling is different.

Why Wasn’t It Internationalized in the First Place?

Venice, Italy

In a perfect world, all products would be created with i18n as a fundamental requirement from the start. But often with new product development, teams are just trying to make a product work and see if there’s a response. The initial focus is on relevance and acceptance of the application. Follow-on efforts are feature focused. I18n isn’t really like a feature, as its requirements underpin an entire application.

As mentioned above, going back and internationalizing code requires a business case. It takes time and will distract the development team from new features. There are times when products are rewritten, which is an excellent window to spend some effort on internationalization. In many cases i18n is a good opportunity for outsourcing, bringing in i18n expertise that allows your team to focus elsewhere, while still learning from the experts to ensure that future development will be internationalized. Expert help enables you to implement i18n faster with greater quality and less project risk.

Although people often think i18n is just about string externalization and the resulting localization, there is much more involved. There are locale frameworks that will govern locale behavior, methods/functions/classes that may need to be changed, static files to alter, and even hard coded patterns (e.g. a hard coded font) that may need fixing. Issues like date/time, address, phone number, numerical and measurement formats will have to adapt to local preferences. You’ll need character support, sorting changes and more. String externalization is like the visible part of an iceberg. You see it, but there’s much more below the surface.

Consumer Facing Software

Vernazza, Italy

It’s easy to see how consumer facing software has a higher requirement for i18n and L10n if it’s to gain broad acceptance, even in markets where English is more common.

That said, we do hear the argument that English is commonly used and understood in many places. Remember, if you travel to major cities in Europe, you’ll find that you can get along with English pretty well. But in terms of product preferences, people typically prefer engaging in their own languages. As you get out of major cities, you’ll find less English proficiency. Even with English (which English?) you still have formatting issues as mentioned, like decimal and comma placement in numbers.

Technical Software

Internationalization Phases

We see the “English everywhere” argument even more with technical software. To an extent, if your users are technical (i.e., system administrators), you can use English in more markets. But you’ll fall flat in Asia Pacific countries, such as Japan, Korea and China.

Below is a broad summary of i18n phases or levels which can be applied depending upon the business case. The best is to be global ready for everywhere of course.

Unicode

If your targets are in Western European languages (i.e. French, Italian, German, Spanish, Portuguese and more), you won’t need Unicode support in your application. That said, if you’re working on i18n, I like to recommend that people take on Unicode as early as possible. Most every modern database and programming language offers Unicode support, but you have to enable it. In our experience, Unicode support can be about 25% more work on an i18n implementation (there are exceptions), but remember that if you’re already in the code making i18n changes, it’s more efficient to do it now than restart the process later. This is a generalization, and there are plenty of specific application, business case and market driven exceptions. For example, somebody sold something and you have to deliver your product in Brazilian Portuguese in three months (true story!).

Unicode support will need to be a prerequisite if you have plans for markets/languages with complex scripts such as Japanese, Simplified and Traditional Chinese, Korean, Vietnamese, Hebrew, Arabic and Cyrillic based languages (i.e., Russian).

I18n Phase 1: Data

Internationalization

The very first internationalization priority should be the ability to input, process and transform customer data. In my opinion, this should be a benchmark requirement for any software that could have global customers or enterprise customers, whether or not localization is considered to be in the future. Note that the U/I is not changing in this phase. There is no U/I localization yet.

Even if you are actively selling only in your home country, it’s likely that you will run into customers in other countries, or your customers will have customers in other countries. At least let people enter data in multiple languages and formats. Store it, transform it and retrieve it without corrupting it.

Minimally, accents and diacritics shouldn’t cause character corruption (those square boxes and odd shapes you’ve probably seen). Better yet, add unicode support in the database and source code.  Character corruption shouldn’t be caused via issues in the various components of your product source code.

Character corruption example:

Character Corruption Example

Better if data can be stored and managed in variable formats for information such as date/time, numerical units, addresses, phone numbers and currencies.

Automation is the best approach to achieving this in a seamless, efficient and scalable manner. To that end, Lingoport’s Globalyzer can be used to scan your source code and database scripts to find these issues and guide developers to fix them. Our services team can perform refactoring work, as well.

I18n Phase 1.5: Locale Frameworks

You’ll need a locale framework for each programming language within your source code.

This paves the way for string externalization and presentation which will be needed for localization. Presentation of formats for date/time, numerical units, addresses, phone numbers, collation, currencies and more are also controlled by locale frameworks.

Lingoport’s services teams can help you make the right choices and even implement them for you.

I18n Phase 2: Language and Localization

Italy

String externalization is often what most people think of as the critical i18n and L10n step. User-facing words or strings are removed from being embedded in the source code and replaced with a function call typically to a resource file where the strings will now reside. This way, if the user selects a locale preference (remember those locale frameworks), French in France for example, the code will retrieve the French strings in the resource file for presentation.

String externalization can be tedious and time consuming. The issue is that lots of things may look like strings at the source code level that aren’t actually user-facing strings. Examples are named variables, debug statements and internal queries. Lingoport’s Globalyzer has default and extendable capabilities to aid these distinctions. Globalyzer Workbench enables an i18n engineer to assemble strings, walk through them and then externalize them in bulk.

You’ll also want to test your work. Lingoport’s Resource Manager will automatically generate a pseudo-locale that will help your team functionally test how the software will behave in another language, without the testers needing to understand that target language. Pad characters are added around the original English strings with expansion automatically set based on typical U/I requirements in the target languages. Alternatively, the expansion can be configured manually. This way, testers can immediately see any missed strings or U/I elements that won’t properly expand for likely longer words and changes in fonts in other languages (i.e., German, Chinese).

Pseudo localized page for a family tree application:

Pseudo-localization

I18n Phase 2.5: Workflow

With some software, workflow and processes are different depending on market requirements. This takes market research and coordination with in-country representation. For instance, tax management, or medical administrative software is likely to have different requirements and steps in most markets.

I18n Phase 3: Bidi Support

i18n Phases

If your product is being sold in places using bi-directional languages such as Hebrew or Arabic, you’ll need to enable and test your pages to support U/I mirroring and the bi-directional nature of text that goes right to left, but with left to right elements within. Unicode support is a prerequisite.

Ongoing i18n and L10n

Fight Mojibake!Now that you’ve internationalized and localized your software, your work isn’t over. Your teams will be steadily releasing new features and functionality. I18n surprises can arise down the line that cost time and iterations to fix. It’s not hard for a developer to make a mistake. Just as your teams may continuously measure for coding quality issues and security, i18n quality now becomes another metric.

Localization for every sprint, branch and repository makes for tedious and error prone work that slows agile progress. That process can be automated, taking your developers out of the resource file update nanny business.

Lingoport Suite’s Globalyzer continuously supports i18n from the developer IDE to source repositories. Lingoport’s Resource Manager automates resource file updates from source to translation and back again, with quality checks in each direction. QA is supported as well.

Lingoport Dashboard lets teams see and manage i18n & L10n status and process, supporting i18n issue drill downs to associated source code, issue assignment and completion. Similarly, Localization resource file issues can be itemized and examined.

We’ve seen teams go from 5-week localization update cycles to under 3-days over hundreds of repositories. Our services teams have internationalized many well known applications ranging from small to millions of lines of code, and you would be surprised to see the efficiency gains that are achievable in the development process.

We hope that you find this primer useful as you look to address i18n and L10n of your own software products. If you have any questions, do not hesitate to reach out and a Lingoport team member will be happy to talk through the issues with you.

Other resources:


The State of Continuous i18n & L10n Survey Results

Bringing Continuous i18n and L10n to Developers

A consistent theme for internationalization (i18n) and localization (L10n) resistance at companies is that developers feel they don’t have time for i18n and L10n tasks. They may not appreciate the issues and view globalization as a distraction from feature development. Creating global-ready and well localized products that keep up with feature development is an important measurable objective for any software company with global ambitions.

I don’t think we’re going to make i18n and L10n exciting for many of them, but we can make it easy, within their workflow, measured and visible.

Collaboration Systems and the Global Software Development Workflow

Slack Integration

Our latest release across the Lingoport Suite adds integration with Slack, Flowdock and Cisco Spark collaboration systems. Plus, we’re ready for other collaboration tools as requested. Our customers have met this new feature with excitement – even more than we’d hoped.

For the uninitiated, Slack and others are messaging tools that have become widespread especially in development teams, within only a few years. They move daily conversation out of the noise of email inboxes and into searchable threads. There’s a bit more to it as well, as collaboration systems extend functionality by connecting to source repositories like GitHub and more.

LingoBotHave You Met LingoBot?

For those extra capabilities, we’ve introduced LingoBot. You can have LingoBot perform tasks like initiate i18n scans, check status and initiate localization round trips, saving your team a great deal of time. The full list of LingoBot functions can be found here: http://wiki.lingoport.com/LingoBot_Users_Guide

Like Broccoli and Ice Cream

We have a bit of a joke here at Lingoport that i18n automation is like eating broccoli and localization automation is like eating ice cream. It’s important for the developers to “eat their broccoli” and make applications global-ready. The Globalyzer component of our suite points out the issues as they work, rather than depending upon traditional, time consuming testing iterations. It creates work in the sense that i18n problems are identified in the course of daily development, but ensures higher quality software and a more reliable global release process.

Localization Automation Like Ice Cream

Then the L10n automation that is delivered through our Lingoport Resource Manager (LRM) is like ice cream, as it makes it so simple, fast and easy that it’s a treat. No more packaging files, inspecting them, sending them off and doing the same thing, plus manually putting them back in the build. Even if teams have scripts to perform some of this, they are still likely pinned down by manual processes prone to human errors that complicate issues down the line. All that’s gone with no extra developer work. LRM helps your team to save countless hours of work in the localization of your software.

Give Lingoport Suite a Try

You can give the Lingoport Suite a try without even registering by playing in our sandbox here: https://lingoport.com/pd/lingoport-suite-sandbox/

If you’d prefer a guided tour, let us know.


State of the i18n and L10n Industry Webinar

Continuous Globalization Makes You Fast and Agile

The localization industry has been late to the party regarding continuous integration (CI) of its services with software development. Continuous Globalization is finally getting the attention it deserves now, and that’s a good thing not only for the software industry but also for end users around the world. Here’s what continuous integration, and more specifically continuous internationalization (i18n) and localization (L10n) are, and what it can mean for your software development process.

The Basics of Continuous Globalization

For the uninitiated, Wikipedia defines software continuous integration, or CI,  as the practice of merging all developer working copies to a shared source repository several times a day. Multiple builds and automated tests and quality profiles are run against the code to identify bugs and other issues quickly. The sooner you find those issues, the less costly in time, effort, and money they are to fix. CI is fundamentally supportive of agile development principles. Automated quality profiles can include coding quality measurements, security, and more.

Lingoport has been working with some of the largest, well known global technology brands with its continuous internationalization suite of software, Lingoport Suite, including internationalization support for developers, QA support, and localization streamlining. These products work seamlessly with agile-friendly localization providers, providing software companies with systems and services to back up their fast moving product development efforts.

Beware the Invisible Costs

Happily, we don’t usually have to extol the benefits of CI to development teams. I’ll also note that internationalization (i18n) and localization (L10n) requirements are far more openly received than years ago.

That said, managers will comparison shop to lower localization costs per word but can inexplicably regard engineering costs involved in chasing i18n bugs, accounting for localization file updates, and iterative testing as invisible. That typical process involves manual, error-risk prone work even if there are scripts involved. If anything goes wrong with file formatting or myriad other nits, the time to trace it back and fix it eclipses a few penny savings here and there, and can be downright costly in financial terms and damaging from a brand perspective when viewed holistically.

For example, if you consider a SaaS application, perhaps with 5 to 15+ simultaneous sprints running at any given time and with three to five developers per sprint team, there is a lot of room for i18n issues to arise. The localization for any particular sprint or release might be quite small. For example: a few words added in one menu, a new error message, and some new functionality that add up to five to 10 new files with an average of 34 words needing localization per file. The minute someone has to manually handle any of that, you’re losing money and momentum. It costs far less in money and time if i18n issues are found right during day-to-day development, and the localization flow from repository to translator and back to the repository is managed automatically, including validation checks.

Dealing with Short, Fast Development Cycles

If your teams are agile (most teams are at least using some form of agile methodology now), it is particularly challenging to include both internationalization and localization processes within a two to three week or shorter cycle. However, we’ve seen clients using systems go from 5 week localization turnarounds, to three days. Consider that if your i18n and L10n are not integrated and automated within your sprints, you are defacto pushing them into the backlog. As your developers move on to successive sprints, if there is a problem with i18n and L10n that needs development and QA attention, they have to stop what they are doing, figure out what the problems are, where they are located, and fix them, and then QA must again verify that fix. That costs time, money, and momentum. It also likely means that your globalized users have to wait for new releases.

Keep in mind that many software development projects are moving to micro services architectures, which break repositories into many little components that get mixed and matched based on product configurations. This makes the business case for continuous i18n and L10n even more pronounced.

Human Factor Issues

Let me give you examples of human factor problems that cause quality, development/QA costs and localization delay issues:

A very common developer practice is to concatenate a string or message to the user. The message builds based on elements such as variables, plurals, and conditions that determine what the software needs to convey. This is how developers are taught to write code. It’s very efficient if there’s only one language involved. Even if that concatenated string is properly externalized, the word order is likely to be completely different in another language, making the translated version at best quaint, and at worst nonsensical. Since the translator doesn’t see the whole string together, they can’t produce a quality translation. However, if concatenations are found right in that day’s work for the developer, correction is quick and painless. Wait until testing, and now we have a multi-step process.

Another example is a developer not using a proper class or method that can support locale, or not passing locale to a class. Perhaps they are using a calendar class, such as SimpleDateFormat (Java). This will render a US formatted date just fine and will pass unit tests, but it’s not going to go well on a system with a different locale date formatting preference.

If you catch these sorts of issues as the developer is writing or committing their day’s work, it’s minutes to fix them. Find them later, and likely QA has gotten involved, the developer has to track down the issue (often not obvious to locate in the code), verify it’s fixed and then update a bug report. It’s no wonder these issues slip in favor of a release date.

Automation, Efficiency, and Speed

For QA, a pseudo-locale is created automatically which adds pad characters around strings so that the tester can see the U/I in English. The pad characters prove that the interface can expand to support likely longer translated dialogs and more complex character sets. Again, nobody has to remember to run a script at some point in time. The updates are automatic and continuous. When the interface is changed by the developer, the pseudo-locale update is automatically updated. This gives QA departments immediate functional U/I test cases for every new feature that confirms to worldwide requirements.

For localization, the changed U/I resource files are automatically detected. Those files are then automatically vetted for quality checks (i.e., no duplicate string IDs, proper file formatting, and more) and sent out for translation or pushed into a Translation Management System (TMS). The localization vendor, which must understand and even thrive in agile localization, then delivers the translations, which are updated leveraging a TMS, Localization Vendor Portal or other translation systems, and our Resource Manager process verifies the file formatting again and takes care of updating the source repository.

Nobody has to track down all the resource files, measure for changes, run a script, verify the file formatting, and figure out issues like duplicate string IDs or silly things like a missing curly bracket in the file format. When the translation comes back, there is no need to manually check the files again, track the fact that some translations came back before others, find a missing translation, or some broken file parameter or encoding. That’s all done. If there’s an issue, it’s clearly described and the fix is fast. If as fallible humans we were to miss any of that, it’s often not detected till much later and even so, it can be hard to unravel. Because there is no human processing delay, linguistic testing can begin faster and within context of the application.

Integrating i18n and L10n has another human factor effect that changes the cultural thinking of the company. When measurement and updating is quick, visible, and relatively painless, you change the way that developers think about globalization requirements. You’ll find teams learn to automatically think about the global implications of their development efforts and the needs of new customers, and factor that into their decisions upfront. As one executive described it, the teams moved from being like a US based company that is looking to do international business, to a global mindset, looking to write software for the world. That makes for global product leadership, rather than a simple checkmark for minimal product requirements.

Strengthening Your Competitive Edge in Global Markets

Remember, there are competitors whose primary model is to copy what is successful in some markets, but use a better localized product to outcompete dominant industry players in new markets. Internationalization and localization are now not just about reaching new customers, they are also about defending customers and capitalizing on new opportunities going forward. What some people think is good enough, is not good enough. It’s best to give your global customers a continuous, excellent, up-to-date experience, or someone else will do that for you.

Additional Continuous Globalization Resources

Bridging Gaps Between Localization & Development

Here’s a 10 minute whiteboard talk posing a solution for gaps in understanding that happen between localization, development, management and QA teams with a focus on agile teams and schedules. Organizational visibility and systems integrated cleanly with build management make for proactive internationalization and localization. We’ll have a webinar with more detail and examples on the subject on October 15th. Learn more and register for the webinar and please watch the video below.

 

Lingoport Resource Manager Released

Connecting Development and Localization, New Technology Automates Translated File Management

Today, Lingoport announced that it has released Lingoport Resource Manager (LRM) to support development projects in their localization efforts. By optimizing the manual and often error-prone process of resource file management, LRM effectively bridges the gap between development and localization, ridding the two areas of unnecessary testing iterations and file confusion.

In a press release sent out today, Lingoport President noted:

 “During our product research for LRM, we saw great demand for an automated resource manager solution yet no commercial product was available. Localization and engineering teams talked about the difficulty in keeping up with changes and even delaying global release versions because of the management and integration overhead. Our solution allows localization managers and project engineers to automatically view changes right at the build/source management level, prepare those files for localization and then reintegrate them back into the product build when translated, along with quality and error checking in every step. LRM particularly helps agile teams with complex applications in keeping up with development changes and translation processes. It makes globalized products easier to keep up to date for every market.”

Lingoport Resource Manager represents the next step in answering how Agile and localization can co-exist. So often we have heard at trade shows and conferences that the two were not made for each other and many outdated localized versions of projects were released without proper translations implemented. This conundrum inspired months of research and development and we are happy to bring our solution to market.

Watch this introductory About Lingoport Resource Managervideo detailing the processes that LRM automates.

For more details on Lingoport Resource Manager or to request a demo, visit http://Lingoport.com/LRM or download the white paper detailing the business case for LRM.

ISO Latin-1 and Canada i18n

Targeting a first time internationalization effort for Canada is one of the more forgiving target locales from a technical risk perspective when working with code that is US English-centric. If there’s a missed string, chances are the user be able to work through it. Currency symbols are represented the same. Numerical units use the decimal point the same. Address formats are the same other than postal codes. However, this can also present a false sense of internationalization compliance. It has consistently been our experience that firms who thought they had internationalized their code for Canada and Canadian French, had much missing upon further examination.

There are a few reasons for this:

  • It’s actually very hard to detect and then measure many internationalization issues. Because understanding of i18n is likely to be limited, there’s a disconnect in the feedback loop to developers when i18n is incomplete.
  • Many developers used on internationalization projects tend to be new to the process and are often not the people who wrote the code. Unless they have powerful tools and strong guidance for architectural changes and planning, they are not going to understand the i18n requirements and be able to fully recognize what changes will be needed – yet they will perceive tasks as completed.
  • Without clear diagnostic tools, it often takes companies at least three release cycles to deal with many stray internationalization issues. New issues tend to crop up with continued development activity. The worst is the first time through.
  • Typically there is an over reliance on creating pseudo-translations and working through a QA process to visually inspect strings. While this is a good process, it is limited by nature in its incompleteness and late and iterative cyclical inefficiencies.
  • I18n is initially understood as a string externalization exercise. While strings are a highly visible component, they are far from the whole story.
  • Locale handling and changes to the database schema represent larger changes that can effect an entire software system. However, they are often implemented the first time in a way that doesn’t account for what is learned later on for more complex internationalization efforts.
  • Programmatically, many things in code can look like strings when looking to find and externalize them. The heuristic logic of this process is difficult, so searching a code base for string externalization usually misses much.

While the above internationalization changes are easy to overlook for Canada, we’ve found that they make themselves more obvious when going to markets, like those in western European locales. They are exacerbated when going to Far Eastern locales, where support for Unicode will require another significant phase of i18n development. Supporting bi-directional languages adds further complication. All of these business developments are greatly supported by using Globalyzer along with additional Lingoport products such as Dashboard and Resource Manager.

Demonstrations of each solution can be requested by contacting Lingoport staff.

Concepts on Being a Globally Aware Company

In preparation for my moderation duties for next week’s 2012 Internationalization and Localization Conference in Santa Clara, I’ve been speaking with the panelists to learn about their experiences over the years in building a globally aware organization.

Some of the information shared with me reflects their systematic approach of shifting more and more of their focus to the start of the globalization process with their internal “customers”, sometimes even before code is written. This focus comes from the years of data they have collected on the cost, time and quality ramifications of shifting issues down the globalization process chain, resulting in other departments have to deal with them – or not at all.

Tools and technology that help organizations collect data, and I mean not just on translation metrics but an overall globalization process, have led to some interesting findings. One panelist on the “Internationalization and Localization Process – How to Make Your Organization Global Aware” will talk about the concept that not all bugs are the same.

What do you mean, Herr Blau? Well, should an embedded string be given equal weight to that of a time/date i18n bug that shows the date incorrectly to a bug that causes data to be read incorrectly with the web application and takes over a week to fix?

The answer to that question, and many more, will be addressed in the panel. The audience also be granted the opportunity to learn from the experts about i.) readiness programs they have instituted, ii.) scorecards that measure globalization acceptance criteria and iii.) how localization can embed into other departments to demonstrate which actions can positively or negatively affect making products world ready.

I encourage you to reach out, comment or email me at ablau(at)lingoport.com if there are other topics or themes you would like me to address to the panel. If you haven’t already signed-up, we only have a few spaces left and now would be a good time to do so to join us in the conversation. Sign up here.

Out of the Flat Black Box: Mobile Apps Localization Strategy

This guest article was authored by Talia Baruch of  Copyous (now LinkedIn).

The Urban Nomad

Sounds familiar? Like someone we’ve transformed into, slowly and steadily, encapsulated by the virtual ritual. Yep, 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, manage photos, read books, watch movies, or just idly slide-flick through its menu bar, while waiting for our transit.  If 2011 was crowned as the year of the tablet, 2012 is the year of the ultra-thin, ultra-light ultra-book black box, leaving laptops and PCs in the backseat.

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’ broader multichannel outreach to consumers. Therefore, when we examine pipeline paths for the localization industry, it is the mobile vertical that frantically calls 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 simship 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.

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. Brazil, Russia, India, China, Japan and Korea are markets with heavily growing mobile traffic use: smartphone sales, apps store installation, ads revenue and virtual goods consumption.

Visibility & Usability

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 three spoken languages: French, German and Italian; three dominant operating systems: iOS, BlackBerry and Android; 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!

Got Game? Measuring ROI of Localized Goods

ROI from localized apps is given, providing you implement sustainable and scalable localization processes and conduct careful market research for product acceptance in new market entry. Electronic Arts’ revamped car racing games localized into Russian yielded a 600% ROI over the English version! Likewise, Julio Vieitez, Director of LUG—distributor of online games in Brazil, reported that a game version localized into Brazilian Portuguese yielded a 15 times higher revenue than the English version in the local market. Not bad for ROI! An example for revenue loss due to mis-culturalization is when “Age of Empire” was localized into Greek. It was banned by the Greek government because of the name “Macedonian.”

Find out who loves your apps and make them love you more. Determine the top-three non-English locales for your apps traction. Localize into these three target languages first, as a tier-one pilot. Not all languages in a localized app will generate significant added revenue. Make sure your translators understand your app and are active users. Detecting terminology nuances is a landmine in apps localization, where jargon and context shape the content. For example, the Chinese translated term for “User” is different in a standard app compared to a gaming app.

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.

About Talia/Copyous

Talia is an independent localization and culturalization consultant with 17 years experience optimizing companies’ international outreach. She founded Copyous, devoted to fitted localization program development and management for companies’ go global goals. Talia is a frequent speaker at principal localization and internationalization conferences and an avid contributor at industry roundtables. Contact Talia at via LinkedIn http://www.linkedin.com/in/taliabaruch and Twitter @TaliaBaruch.

Localization Strategies for Global E-Business

Lingoport is proud to have collaborated on Localization Strategies for Global E-Business by Professor Nitish Singh, PhD, Associate Professor of Int. Business & St. Louis University Director Alternative Delivery Programs. The book is out now and is available on Amazon and the Cambridge University press websites.

A major focus of Singh’s book is on internationalization, a point of expertise of Lingoport. Lingoport President & CEO Adam Asnes is featured a number of times from describing the best i18n support technologies to the necessity of Unicode in a project.

Preface for Localization Strategies for Global E-Business

The acceleration of globalization and the growth of emerging economies present significant opportunities for business expansion. One of the quickest ways to achieve effective international expansion is by leveraging the web, which allows for technological connectivity of global markets and opportunities to compete on a global basis. To systematically engage and thrive in this networked global economy, professionals and students need a new skill set; one that can help them develop, manage, assess and optimize efforts to successfully launch websites for tapping global markets. This book provides a comprehensive, non-technical guide to leveraging website localization strategies for global e-commerce success. It contains a wealth of information and advice, including strategic insights into how international business needs to evolve and adapt in light of the rapid proliferation of the ‘Global Internet Economy’. It also features step-by-step guidelines to developing, managing and optimizing international-multilingual websites and insights into cutting-edge web localization strategies.

Book Features

• A comprehensive, non-technical guide to tapping the growing global e-commerce market with ready-to-implement localization strategies for effective international web presence
• Presents a blend of strategies, models, checklists, tools, research insights, examples and cases to help readers comprehend the complexities of global e-commerce
• Shows how to avoid common web localization mistakes and, in the process, achieve significant cost savings

The book is available for purchase on Amazon.com.

Upcoming

Singh presented a well-received presentation at last year’s Worldware Conference entitled The Rise of Chindia: Opportunity or Threat? The video is available here.

In the absence of the Worldware Conference this year, Lingoport has stepped to the plate to bring the 2012 Internationalization Conference. The conference features several great internationalization and localization tracks as well as an in-depth pre-conference i18n training course.

CNGL Launches Localization Careers Guide

Centre for Next Generation Localisation (CNGL) releases guide urging secondary students to consider language and technology for a potential career

Crafted by Sean Sherlock T.D., Minister for Research and Innovation, the guide is an effort to maintain Ireland’s leadership position in the multi-million euro localization and global services sector. The guide is being distributed to all secondary schools in Ireland this week and features profiles of top professionals, companies and courses to help students get on the right track for a career in localization.

Mr Sean Sherlock, TD, Minister for Research and Innovation, pictured with Prof Josef van Genabith, Director of CNGL, at the launch of CNGL's Next Generation Localisation Careers GuideSpeaking at the launch, Minister Sherlock stated “Many of the world’s largest software and web companies co-ordinate their localization activities in Ireland and the sector contributes an estimated €680 million annually to the Irish economy. It is imperative that we highlight the opportunities available to our young people in this sector.”

For more information on CNGL and the Localisation Careers Guide, please visit: http://www.cngl.ie/careers.html

The guide can be downloaded in PDF form here

For educational resources on internationalization, please visit https://lingoport.com/whitepapers