Welcome to the world of Infosys Engineering! It is a half a billion plus organization that takes pride in shaping our engineering aspirations and dreams and bringing them to fruition. We provide engineering services and solutions across the lifecycle of our clients’ offerings, ranging from product ideation to realization and sustenance, that caters to a cross-section of industries - aerospace, automotive, medical devices, retail, telecommunications, hi tech, financial services, energy and utilities just to name a few major ones.

Internationalization and the development life cycle

As a product company your team has come up with a brilliant concept which has tremendous marketing potential in your country. Your marketing survey shows that the concept will soon catch up with other countries across the globe and you can capture the overseas market too. The only catch is that the product will be required to be globalized before it is launched in the international markets. A global launch is still 5-6 months away, so what product strategy will you adopt? Develop the product in English and later when you have access to the global markets, think of internationalizing it or start developing an internationalized version of the product right from conceptualization stage so that you are ready to penetrate the global markets when the time comes? This is a question most product managers will face while developing a product.

The ideal time to start thinking about Internationalization or Localization of your product is at the conceptual stage of the product development life cycle. The product management has to be clear about their vision for the product. If the product is meant for international audiences, it is a good idea to plan for it earlier than later since it will definitely be more expensive to do the same thing later and you may also lose out on market share due to a delayed launch. Internationalization is often more important than localization in the development stage since localization will normally not involve code re-engineering whenever it is done. Think about a product which is not internationalized and you want to introduce multilingual support to it. Changes will have to be made in multiple layers in order to achieve this. These changes will be costly in terms of the time taken, bugs introduced and additional testing required. However if the product architecture had made the same provision at design time, things would have been much simpler and all the development team had to do was get the string resources translated in order to support a new language.

What does it take to internationalize your product right from requirements to design to development and finally testing? The requirements gathering team must understand the typical i18n requirements and they must evaluate the product requirements from an i18n perspective too. The design team must understand the typical i18n aspects and ensure that the product design takes care of all i18n issues along with the intended architecture and design. The development team should be experienced with making i18n related code changes and it is important that they understand the i18n best practices in order to avoid rework later. The development of the core components and internationalization must go hand in hand. Pseudo-localization testing must be planned for the product to identify potential localization issues. If these practices are followed, it is more or less assured that it will be easy to adapt the product to different regions or countries as and when required with minimum cost and time to market.