Including i18n support in your software involves more than writing some code. Successfully implementing internationalization also requires planning, some strategy, and long-term support. These tips will get you on the right path whether you’re starting a new project or adding i18n support to legacy software:
1. Learn, Build, and Support the Business Case
Continuous i18n and l10n in support of agile development comes with 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 practically every part of your application; It isn’t like adding a feature, or fixing a bug, in a particular sprint and code segment. Internationalization usually involves more than your software’s presentation layer because data is input, stored, transformed, and retrieved — not just viewed. 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 for every target locale. i18n is almost never just a string externalization exercise you can pass to an intern. You need to put some real thought into locale requirements; how data is going to flow through your application; changes to your database; methods, functions, and classes that need to be locale-aware; and, of course, the UI and all its strings.
4. Build a Plan
An i18n project plan typically starts with about 200 tasks and increases with size and complexity. That’s something to keep in mind for multi-tiered applications. To build this type of plan, analyze the code base with Lingoport’s Globalyzer, which provides a detailed static analysis of internationalization issues that need to be addressed. Combine that with architectural analysis from whiteboard discussions and requirements documentation. You can learn more by watching our i18n Planning webinar recording.
5. Reduce Risks and Manage Trade-offs
Being late in deploying your global software is a costly business mistake. At risk are potentially broken agreements, missed market launches, and business plan failure. A three-month delay may make an annual revenue goal unattainable. Ensure your executive management team is fully on board with 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 a lot of legacy code, you may need an implementation partner to help 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, and don’t wait until testing to find out if i18n is broken. It’s good for agile development to automate the management of strings that may change as new releases roll out. You can learn more in our Lingoport Resource Manager: Automated File Management whitepaper and Analytics for Internationalization – How to measure internationalization webinar recording.
10 Common Mistakes to Avoid in Software Internationalization
Internationalization can lay the groundwork for successful software launches around the world. Avoiding these common mistakes can save time, money, and frustration — and potentially even avoid failing in various markets:
1. Don’t Forget What Drives Internationalization
Internationalization drives your company’s top and bottom lines. The cost 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 framework you’re using today, internationalizes itself. You still need to perform all the steps necessary to implement locale, along with all the associated i18n practices.
3. Don’t Assume You Can Treat Internationalization Like Any Other Feature Improvement with Source Control Management
It’s typical for new feature development and bug fixing to be conducted in parallel with i18n. In the process of performing i18n, however, you’re going to be breaking major pieces of your application’s functionality when making large changes to your database and other application components. In order for 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, refactoring data input methods, functions and classes, and manipulation and output.
5. Don’t Forget to Give Users a Good Locale Selection Experience
Designing the way the locale is selected and managed often doesn’t get the amount of thought and planning it deserves. How the application interacts with the user, detects or selects locale, and then how it correspondingly behaves is a design process that needs input from an experienced architect, product marketing, and the development team.
6. Don’t Create Your Very Own Internationalization Framework
Too many companies have implemented internationalization poorly, using their own homegrown methods for string extraction and locale management. Instead, they should’ve used already well-established methods provided in their programming language framework or established solutions like ICU. Using these solutions ensures your code is far easier to maintain without unpleasant surprises.
7. Don’t Think Your Software Internationalization Team Can Do Their Job Without a Working Build
Without a working software build, developers can’t smoke-test the changes they’re making. Even with a dedicated QA person, developers need to be able to compile and run code themselves to head off problems later. It’s too hard to rely on reconstructing coding errors later and makes for unnecessary bug-fixing iterations, lost time, and poor quality.
8. Don’t Run Out of Money
I18n planning often suffers from underscoring. Lapses in funding can cause expensive delays because new funding takes more time than expected to get approved. Chances are, if you need to ask for more money, you also need more time, which brings you back to the consequences of tip 1.
9. Don’t Use a Half Thought-Out Character Encoding Strategy
Use Unicode instead native encodings. If you’re dealing with 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 using ISO Latin–1. That said, it’s still necessary to support Unicode for Eastern European languages. Also, make sure your encoding works throughout the entire 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 to test more than just the application interface. Test data using target character sets, locale-altered date and time formats, phone numbers, and more from data input into the database, reports, and so on. Expand data fields to fit physically longer strings in pseudo-localization testing to account for expanded strings from translation. Pseudo-localization is automated when you use Lingoport’s Localyzer.
Want to learn more about common i18n issues and how to prevent them? Check out our Common i18n Gremlins and How to Squash Them webinar recording.
