Adam Asnes is president and CEO of Lingoport.
Mind the gap:
Development and localization
The gap between localization and development has been an ongoing pernicious complaint in our industry since before I jumped in some 20 years ago. That said, there have been remarkable improvements in development and localization practices.
At least in my corner of the world, we collectively spend less time convincing people of the basic need to internationalize and localize than years ago, though executive buy-in remains an issue at some companies even when they are global operations. Companies and personnel are quicker to understand the technical challenges and they want sustainable solutions. That said, there’s still a lot of room for improvement.
Emphasis on agile and continuous development brings software users new functionality quickly, with controlled risk, faster execution, feedback and adaptation. Delighting customers with new features has become simply what is expected. Similarly, localization delivers customer delight for those outside “home” markets. Localization is performed to raise the appeal and competitiveness of software in any particular market. It behooves our industry to look for ways for localization to keep up with the pace of software development.
My company runs an annual survey of industry stakeholders, targeted at software development rather than the broader localization industry. One open-ended question asks for the most important internationalization (i18n) and localization challenge facing the respondent’s company. Common answers relate to the lack of a consistent system and approach, and difficulties matching localization with agile development. Funding and company buy-in obstacles were also commonly reported.
The most frequently reported issues involved difficulties supporting agile development and consistency in approach and adaptation of i18n and localization across the company. For example, one respondent stated, “For most of our company’s development teams, the technology is so challenging and the deadlines so tight that localization is just one more item on the development schedule. So localization becomes one of the last hurdles before shipping worldwide.”
I can sympathize with this predicament; however, given that my company’s mission is to integrate i18n and localization into development processes, I can see that a big contributor to making localization an afterthought is that most have not kept up their processes and technologies to match the cadence of development. Many of our other survey questions asked about simple processes involving i18n testing, pseudolocalization and turnaround times for new feature localization. Far too many — usually 70% or more — were not using any automation to support i18n and localization.
Continuous systems for i18n and localization should first make it straightforward to write internationalized source code. Fixing issues during development is by far the cheapest time, rather than during testing or after localization. We accept systems that analyze code for security and bugs. An administered system for i18n can do the same, reducing i18n backlogs later on.
Making changes to localization is a matter of automating change management. It is surprising that companies still have to wait for an engineer to manually handle resource files, sending them out and then getting them back, aggregating them and placing them in a build. That increases the chance for human error, plus there’s a likelihood of even simple tasks of this nature getting bogged down in a queue of to-do lists. It’s no wonder many companies in our survey that already localize only update localization one to four times per year, even though they are providing product updates far more frequently.
When a continuous system is actually a person and perhaps a spreadsheet, it’s going to have costly limitations — even if you’ve “always done it that way.” Consider that many products have tens to hundreds of git repositories and branches, all changing with their latest sprint. When you have one localization team supporting an enterprise, you can see clearly why traditional methods won’t allow localization to move at parity with development.
The full scale of continuous localization should streamline at code creation (i18n), functional QA, localization file handling and linguistic QA. Solutions should work fluidly with development, with clearly actionable error handling and collaboration. Remember, pushing out a bug report with a screenshot of an issue means that a developer must stop what they’re doing and figure out where that issue exists, fix it and then test it again. If a person has to touch a file from the latest sprint that might only have a few handfuls of words needing a localization update, you are automatically losing money.
Just because this may not be a line item localization expense to an outside vendor, doesn’t mean it is without cost. That real cost is a major part of why development may push localization aside as it interferes with their feature commitments.
All of this can seem overwhelming if you’re still convincing teams that localization should matter. If you need to raise awareness, remember that localization goals are exciting. It’s not really about the process or the words. There’s a story to tell of new users, empowered solutions and company growth. Get some backup and input from field partners like sales, distributors and customers. Have repeated celebrations where you bring forward some globalization story. Teach people about why it matters and who will be impacted. I remember one such event at Twitter from years ago, where they essentially made global stakeholders and influencers into rock stars. But even simple lunch and learn sessions can go a long way. Need material? Feel free to reach out to me or just use the search box on our company blog.
Don’t keep doing things the way you’ve been doing them if you want to bridge a gap.