Global opportunities are going to force you to evaluate how to adapt your code and ongoing development to support localization. Sometimes it starts with a potential new partnership, sale or strategic initiative. Yet it’s not clear what will be involved for development. When you manage internationalization poorly you create unknown risks to your budget, timing, resources and strategic objectives.
You may know some of the basics or even been through a project like this once or a few times before, but it’s typically a messy, poorly enumerated, trial and error process. It’s distracting to other development objectives while containing unknown risks to your budget and timing.
Here’s a brief guide towards a successful implementation:
1) Learn, Build and Support the Business Case – Internationalization (i18n) and ongoing localization (l10n) is going to have a significant cost and unless the business case is defined, the project is unlikely to get done. Even if it seems like that should be sales and marketing’s job, you’ll need to have some parameters as budget can cause some trade-offs. Companies should not go into globalizing product development without clear commitment, as a bad final product may hurt sales goals more than it helps. A failed i18n initiative can be harmful to your own company objectives as well.
2) Clarify Your Global Release Objectives and Concurrent Development – i18n isn’t like planning a feature release. It’s likely not to fit neatly with whatever concurrent sprint your team is planning. It 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. You’ll need a branching, merging and testing strategy that covers the full i18n scope. Keep that in mind as you go through the next two steps.
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 it’s strings. At a higher level, there are some products that need rethinking in terms of user workflow for different countries. Write those i18n requirements down in a document. That will help you organize for the next process.
4) Build a Plan – Tasks, Time, Cost, People and Dependencies. This is an essential step and even if you’re the type that thinks project plans are meant to be broken, you need to do this and do it to a granular level. When we work on a project we typically build a plan that starts with about 200 tasks and goes upwards with size and complexity (consider this for multi-tiered applications). To do this, we analyze the code base with our software product, Globalyzer, which gives us detailed static analysis on internationalization issues that will need to be addressed. We combine that with architectural analysis from whiteboard discussions and requirements documentation. Building a plan will give you a realistic check on the business case as well. That feedback to business case can have an effect on activities like phasing various levels of functionality if that’s appropriate to your user requirements.
5) Reduce Risks and Manage Trade-offs – Every development project has its risks. In the case of i18n, being late is very expensive. The risk can be a broken agreement, market launch and business plan. A three month delay may make an annual revenue goal unattainable. Due to a lack of understanding of requirements and scope, poor internationalization will result in a poor localization outcome. If after all that investment, the end product can’t be properly executed, then it’s self defeating. There’s also the risk that due to distractions and/or misdirection, you don’t get the work done and the project just dies or hangs in limbo. As for trade-offs, internationalizing a large application is generally resource intensive. It’s a solid assumption that development teams don’t have lots of people with nothing to do, so 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 ongoing development has a new set of requirements. You’ll want to measure internationalization just like any other coding quality and ideally not have to wait until testing to find out if i18n is broken. For your ongoing agile development, it’s good to automate managing changes to strings that may change somewhat with every release. This keeps you from having to do engineering bookkeeping to process the localization of those 26 or so new words that may need translation into your supported languages in the latest sprint.
Our Globalyzer software is a keystone to our services operations when clients hire us to provide internationalization consulting and implementation for them, but it’s also important for our clients in supporting development teams in their initial and ongoing efforts to create and maintain software for global customers, faster, better and with less headaches.
Learn more about managing internationalization:
Agile and Localization:
https://lingoport.com/whitepaper-path-agile-localization/
Internationalization Planning:
https://lingoport.com/internationalization-projects-not-simple/
Measuring Internationalization and Localization:
https://lingoport.com/measuring-internationalization-lingoport-dashboard/
