We get this question a lot. So let’s take a moment to revisit what exactly is i18n.
Introduction
What do we mean by internationalization? Let’s say your company lands a new contract with a company in Japan, or your management team is looking to make an aggressive push into the EU. Your software needs to be able to adapt to those new locales. Internationalizing your software is the path toward meeting the needs and expectations of local users in those markets.
Internationalization (i18n) is the process of preparing software to support local languages and cultural settings. An internationalized product adapts to the requirements of local markets around the world, functioning appropriately based on local norms and better meeting in-country user expectations.
What is Internationalization?
i18n is often misrepresented as Localization (L10n) and sometimes even Translation. i18n is product development focused so that, in the case of software, one code base is made capable of supporting worldwide languages and locale-specific formatting and behaviors. It’s a critical and sometimes underestimated step necessary for a successful and scalable L10n.
Localization makes a product, specific to a target market or region(s), including translation of the interface, possible adaptation of terminologies, and more.
Releasing software that has not been properly internationalized can lead to many problems, including lack of market acceptance. Addressing and fixing i18n bugs after product release results in additional costs, time, resources, and a potentially damaged reputation in local markets.
Retrofitting a product for a global market after release, in contrast to internationalizing the source or during development, can be time-consuming, costly, and provide alternative products with a competitive advantage.
Traditionally, i18n has been a slow, bug-ridden process. Lingoport is trying to change that process to allow i18n at the speed of development.
Why Continuous i18n and L10n are important:
In practice, most software development endeavors treat localization as a delayed and often manually managed process, outside of ongoing sprints and releases. This is contrary to agile and good software development management practices.
There are all kinds of “bookkeeping” issues around managing what’s changed, missing files, getting it out for localization, then putting it back in the source code. By its nature, this delays the process lends itself to handling errors later when the teams have moved on, shortchanges QA efforts, and delays localized releases. It’s costing you time, headcount, and cleanup, and it impacts the global imperatives of your company. Continuous i18n and L10n is simply a much more effective strategy.
What Does Software i18n Involve?
Typical software internationalization tasks include:
- Developing software to be independent of a specific language or limiting character set, and independent from cultural conventions (e.g., date display, time display)
- Locale Frameworks
- Achieving Unicode compliance
- Elimination of hard-coded text (strings) in the code
- Removal and reworking of concatenated strings
- Support for collation of data
- Support for bi-directional languages, such as Hebrew and Arabic
- And so much more, including issues that may be application and market specific
Benefits of Internationalizing Software
Your company will see the benefits of software i18n including:
- Higher quality software that meets the technical and cultural needs of multiple locales
- Reduced time, cost, and effort for localization (L10n)
- Single source code for all languages of the product
- Simpler, easier maintenance for future iterations of the product
- Greater in-country customer acceptance and satisfaction
Challenges of Internationalization
Understanding the market
As companies launch in new markets, they need to understand that what works well for one market might not work so well in another and that there are specific local nuances users may need or expect to understand the service.
i18n and Locale-specific adjustments allow companies to pivot and address the needs of potential users in diverse nations, and provide software that is both useful and relevant to them. Ensuring a smooth transition from country to country is one way that Lingoport can help you overcome these challenges.
Underestimating Time Needed
Internationalization and Localization can be a time-consuming process and requires resources from your team. For more efficient completion of software changes and updates with i18n, you can look to Lingoport for help.
Often, teams believe that i18n and L10n must be completed after full software development in their local market, but this can add months to the process. Working on i18n during the development process using agile methods rather than a waterfall approach can save time, and resources, and bring your product to market more quickly. Tools such as Lingoport’s Globalyzer and Localyzer can save your company valuable time and resources when performing these essential processes.
Internationalization ≠ Translation
If you’re running a software company, it is imperative to know that i18n and L10n involve not only language but formatting for numbers, dates, times, addresses, phone numbers, currencies, and non-textual elements like images, sounds, and videos.
By adapting products for international audiences and understanding how cultural differences can influence their perception of a product or service you can incorporate changes during development to address global markets. If you want to globalize your business effectively, companies must create consistent, relevant content across all aspects of their software.
Developers have traditionally been focused on features, design, delivery, and deadlines. By incorporating localization during development you’re letting them keep that focus and making localization an easier to manage step in the development process. No more post-development localization woes, more time to broaden your global reach.
i18n Stories
Companies come to Lingoport with their i18n problems, so we’ve seen a lot that can go wrong with global software releases. Here are some brief examples:
Bugs, bugs everywhere
One company had been internationalizing for years but had persistent i18n bugs that garnered complaints. When counted, there were nearly 500 bugs on one product alone. That’s a significant impact, they can be expensive to fix, and bugs may be distracting from new features.
By using Lingoport software to support ongoing development, they can now measure and fix i18n issues during development, which is much faster and results in a higher quality global product experience. Using Lingoport’s Globalyzer and Lingoport services assistance, they are working their way through the i18n bugs.
Shipping Off i18n
Still another company knew they had an i18n business case, but it was not immediate. They hired summer interns to externalize strings and perform minimal i18n adaptations. Without good direction or appropriate skills allocation, they didn’t get very far. Then they sent the i18n offshore to a general contractor, spent over $500,000, and still didn’t have a properly internationalized application. In the meantime, they didn’t feel they were much closer to product readiness and were passing up new opportunities.
Continuous Internationalization & Localization
Agile development has changed i18n and L10n tasks dramatically, as software changes faster but in smaller increments. It’s easy for i18n and L10n to fall behind. In the world of i18n, it’s often not apparent to a developer that there is an i18n problem in the code they are writing, as the scope of i18n is broad and there are QA challenges.
For L10n, there is all kinds of management and manual task overhead, as files get moved around and updated. We believe that some of the biggest globalization efficiency gains for software companies to realize will be in systematically and continuously integrating i18n and L10n with agile teams, rather than hoping to find and fix issues in QA cycles when the development team may have moved on.
The key here is automation. Not necessarily of the actual translation via some machine translation, but by managing legacy and new development for i18n issues. This can be done by moving files for localization from the build to the translator and back again in a very visible and verified manner.
To do this, we automatically monitor software code repositories for i18n and L10n changes and issues/violations.
Continuous i18n and L10n features include:
- Visibility – Dashboard measurement and drill-down of i18n and L10n violations and changes via static analysis of source code repositories including tools for fixing problems early during development
- Automation – i18n support in the developer’s IDE, upon check-in and regularly run on targeted source code. Automated analysis, verification, and exchanging of localization resource files from the build to translation (or translation management technologies) and back again to the build for staging and linguistic QA
- Metrics – Tracking progress, coding quality, translation timing, and more so that you can plan and improve
- Integration – Integration with the tools that you are already using, such as a Translation Management Solution (TMS) and Slack for communications
As you add and update features and locales to your software, continuous i18n and L10n give you an automated framework for faster, trouble-free global releases.
i18n Implementation Tips
For legacy i18n refactoring and new development:
1. Learn, Build and Support the Business Case
Continuous i18n and localization (l10n) in support of agile development is going to have a cost. Unless the business case is defined, the project is unlikely to get done. Make sure you build a strong business case to compel all team members to align on i18n implementation.
2. Clarify Your Global Release Objectives and Concurrent Development
i18n touches a good deal if not all of your application, rather than being like adding a feature or fixing a bug in a particular sprint and area of your code. It usually involves more than your software’s presentation layer, as data is input, stored, transformed, and retrieved. When internationalizing your product for the first time, you’ll need a branching, merging, and testing strategy that covers the full i18n scope.
3. Assess and Document Requirements
Establish user requirements as they relate to target locales. i18n is almost never just a string externalization exercise you can pass to an intern. You’re going to need to put some thought into locale requirements, how data is going to flow through your application, changes to your database, methods/functions/classes that will have to be made locale-aware, and of course the U/I and all its strings.
An i18n project plan typically starts with about 200 tasks and increases with size and complexity (consider this for multi-tiered applications). To build this type of plan, one option is to analyze the code base with Lingoport’s i18n software product, Globalyzer, which provides a detailed static analysis of internationalization issues that will need to be addressed. Combine that with architectural analysis from whiteboard discussions and requirements documentation.
5. Reduce Risks and Manage Trade-offs
Being late in deploying your global software is very costly to your business. The risk can be a broken agreement, market launch, and business plan. A three-month delay may make an annual revenue goal unattainable. Ensure that your executive management team is fully invested in your i18n efforts and that your team has the budget, resources, and tools to get the job done efficiently, reliably, and successfully.
Internationalizing a large application is generally resource intensive. In cases where you have lots of legacy code, you may need an implementation partner in order to keep up with ongoing development objectives outside of internationalization.
6. Long Term Support
Once you internationalize and localize your software, your ongoing development has a new set of requirements. Measure i18n just like any other coding quality. Do not wait until testing to find out if i18n is broken. For your ongoing agile development, it’s good to automate the management of changes to strings that may change somewhat with every release.
Common Mistakes Made When Trying to Internationalize
Be sure to avoid these 10 common i18n process mistakes:
1. Don’t Forget What Drives Internationalization
Your company’s top and bottom lines. The costs of being late or delivering lousy quality products endure beyond any benefits of cutting corners on development.
2. Don’t Assume Internationalization Is Just an Older Software Legacy Issue
No framework, whether it’s React.JS, J2EE, .Net, Java, Ruby on Rails, PHP, or whatever is new and improved, internationalizes itself. You still need to perform all the steps necessary to implement the locale and all the associated i18n practices.
3. Don’t Assume You Can Treat Internationalization Like Any Other Feature Improvement When It Comes to Source Control Management
It’s typical for new feature development and bug fixing to be conducted in parallel with i18n. However, in the process of performing i18n, you are going to be breaking major pieces of functionality within your application as you make large changes to your database and other application components. In order for respective developers to work on their own tasks and bugs, you typically need to branch code, often with specifically orchestrated code merges.
4. Don’t Assume Internationalization Is Just a String Externalization Exercise
String externalization is important and highly visible, but the scope of i18n includes so much more. For example: creating a locale framework, character encoding support, major changes to the database, and refactoring of methods/functions and classes for data input, manipulation, and output.
5. Don’t Wing It on Locale
Designing how locale will be selected and managed often doesn’t get the amount of thought and planning deserved. How the application interacts with the user, detects or selects locale, and then how it correspondingly behaves is a design process needing input from an experienced architect, product marketing, and the development team.
6. Don’t Create Your Very Own Internationalization Framework
Various companies have halfway implemented internationalization using their own homegrown methods for string extraction and locale management when there were already well-established methods provided within their programming language framework or established solutions like ICU. Using these methods or solutions will ensure that your code is far easier to maintain. No unpleasant surprises.
7. Don’t Think That the Team Internationalizing Your Software Can Work without a Working Build
Without a working build, the developers can’t smoke test the changes they are making. Even if you provide a dedicated QA person, developers need to be able to compile and run themselves to head off problems later. It’s too hard to rely on reconstructing coding errors at a later time and makes for unnecessary bug fixing iterations, lost time, and poor quality. It’s odd that we even have to mention this, but it comes up.
8. Don’t Run Out of Money
i18n planning often suffers from underscoping. Lapses in funding can cause expensive delays, as new funding takes more time than anyone imagined to get approved. And chances are if you need to ask for more money then you also need more time, which brings you back to consequences regarding tip #1.
9. Don’t Use a Half Thought-Out Character Encoding Strategy
Use Unicode, rather than native encodings. If you have budget and time constraints and you’re only targeting dominant languages in markets like Western Europe, and North and South America, you can often get away with ISO Latin – 1, but even for Eastern European languages, go Unicode. Then when you do, make sure your encoding works all the way through the application.
10. Don’t Use Your Same Testing Plan, or Just Rely on Localization Testing, When Your Functional Testing Needs to Grow to Include Internationalization Requirements
Use pseudo-localization of not only the interface but send test data using target character sets, locale altered date/time formats, phone numbers, and more, from data input to database, to reports, and so on. In your pseudo-localization testing, expand data fields to fit physically longer strings, accounting for expanded strings from translation. Pseudo-localization is automated when you use Lingoport’s Resource Manager.
Lingoport’s Market-Leading i18n Software & Services
Lingoport is the premier i18n software and services company in the market. If you are looking for software, or for i18n assessment, consulting or implementation services, we encourage you to explore the following links and to contact us at any time.
- Lingoport Globalyzer – Find and fix i18n bugs. Lingoport Globalyzer is your operating system for exceptional global software. Avoid rework. Find and fix i18n issues as the code is written. Default rules and machine learning pinpoint existing i18n issues in source code for a wide variety of programming languages and database scripts. Improve your agile software development for global markets with Lingoport’s flagship i18n software.
- Localyzer – retrieves strings from your software repositories automatically for translation, and deploys them when complete. Set it up and it just goes.
- LocalyzerQA – it’s like the Grammarly of globalization. LocalyzerQA accelerates the process of finding and fixing your linguistic errors. What used to take 20 steps has been reduced to three simple steps:
- Navigate the user interface through LocalyzerQA and click on the words you want to change
- Enter your changes in the application using LocalyzerQA
- Submit for approval
- Lingoport i18n Services – Benefit from our years of experience. Enjoy expert teams for software i18n assessment, planning and implementation.
Lingoport provides a broad range of software internationalization (i18n) services, customized to fit your release goals, technologies, engineering resources and budget. Our extensive globalization experience, Continuous Globalization methodology and powerful products support getting your global releases out on time, on budget and on quality.
Your development team can focus on new features, while we help you meet globalization deadlines and save you from countless hours of post-release debugging and firefighting.
