Many companies with complex software start out knowing they need help meeting product globalization objectives, but they are still new to what help they will need and where technology and language distinctions lay. That’s confounded by grey areas that sit in between internationalization and localization.
Just recently I got a call out of the blue from a colleague who leads his own internal internationalization (i18n) team at a well known software company, with many leading commercial products. The discussion particularly related to best practices and turning information into actual plans.
A local leadership conference a few years ago featured a live panel discussion including Eric Schmidt, CEO of Google, and Michael Moritz of Sequoia Capital, a Google’s investor and board member. The first question tossed out was: what makes a company great? Mr. Schmidt quickly answered,
There are two kinds of software internationalization you can refer to – built in to the product from the start, and performed on existing code. The kind of internationalization (i18n) this article invokes isn’t the sort that’s designed into a product right from conception. That is less common, though the pull of global markets is changing that tide.
Just last week I visited with a past customer with a possible new project. Actually I was there primarily discussing implementing Globalyzer, and they brought up the possibility of having our team provide services for them.
The situation was not unusual in that they had clear high-level directives (as in get it done yesterday) for the internationalization effort,
You’ve just received a request to prepare your software for sales opportunities in China, Japan and Germany. Your code base is large, maybe you don’t even know how large, but it’s had years of development. The question is how do you tackle the problem and successfully internationalize your code without expensive surprises and delays? Regardless […]