Lingoport’s Internationalization Approach

Internationalization tools and software localization project scheduleYou’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 of the size of your code base or what technologies you use, several key actions must be performed in order to create a product that works elegantly anywhere in the world. This document summarizes those actions and how Lingoport’s Globalyzer software, a leading software internationalization tool, enable seamless internationalization of code and long term maintenance.

Planning and Requirements

Internationalization projects can be strategic, tactical or both, depending upon the impetus to perform the effort. Whether internationalization is being pursued as an immediate response to a client opportunity or as a long planned effort to reach new clients in foreign lands can determine the pace, phasing and scope of internationalization. The easiest markets to internationalize for are countries with locale requirements which can be supported using ISO-Latin 1 character sets. These include Western European countries, the Americas, Australia and more. Bi-directional languages, such as Arabic and Hebrew have their own challenges. It can get one step more complicated to support Eastern European locales and further challenging to support “double-byte” languages such as Japanese, Chinese and Korean, using Unicode (though Unicode support should become part of your eventual, if not immediate internationalization plans). The right phasing will depend on a company’s opportunities, technologies and limitations.

Locale support requirements will also affect application logic and formatting. This includes I18n issues such as phone numbers, addresses, dates, times, sorting orders, units of measurement, currencies and more.

Locale selection and application behavior also needs to be defined. For example, is the user’s locale being selected based on the browser setting, or based on account preferences? Does a user need to access or enter data in more than one language?

Technologies from programming languages to databases and third party products will have their differences in how they support locale and character sets.

Creating an internationalization architectural document and project plan, gives the development team a clear roadmap while accounting for requirements and technologies. It also provides a resource that can be followed throughout a product’s lifecycle.

Database Refactoring

Often the first area we will address is migrating the database to the chosen encoding and multi-locale schema. This usually has far reaching implications for many software applications, touching upon how data is stored and retrieved.

String Identification and Externalization

Strings that are embedded in source code and will be seen by a product user, in most business cases, will have to be extracted from the code so they may be translated, and then the corresponding string must be presented to the user depending upon locale selection. However, there are lots of strings in your software that are really debug statements, database queries and the like, which will never be seen by a user, much less ever need to be translated. You have to sift though your code for what you need, and eliminate what you don’t. Then you have the process of externalizing all the strings. That’s slow and tedious work without the right tools and process.

Refactoring of Locale-limiting Methods/Functions and Web Page Encoding

Chances are that all through your code there are methods/functions and pages that won’t properly support your locale requirements. Issues can include support for character encoding, date/time/number fixed formats and the like. These have to be identified and fixed.

Third Party Products

Often software can include the use of third party products that may be used for anything from data input/output, graphics, reporting and more. Third party products need to be researched for any character corruption or locale limitations they may cause, and then rectified. This area can particularly cause surprises, as support isn’t always as claimed.


You need a way to test your application, without requiring your engineers to speak all your target languages. You need a plan and set of procedures to simulate supporting your new locale requirements.

Lingoport’s Approach

Lingoport offers both knowledgeable internationalization architects and engineers while also being the developers of Globalyzer, software for analyzing and performing internationalization efforts. By combining strong analysts with Globalyzer, a leading software internationalization tool, you can attack internationalization challenges based on optimizing internationalization architecture together with comprehensively analyzing internationalization issues buried in your code.

Analysis, Architecture and Planning

Our first step is to meet with your team, including product managers, marketing staff, developers and management to evaluate and develop requirements and plans. Simultaneously, we analyze your source code using Globalyzer, giving us a clear count of internationalization issues that will have to be rectified. We can then apply our metrics, both architectural changes needed and Globalyzer measurements, to accurately estimate internationalization development tasks.


During development construction, we actively use Globalyzer to speed up finding and fixing issues in code, including a wide range of programming languages and even database scripts. Our engineers have strong successful experience internationalizing all kinds of software, which makes the work move along well. We can also parallelize our work with your development team using Globalyzer’s client/server architecture to help us coordinate our efforts together.


During testing we use Globalyzer’s PseudoJudo to “pad” strings in resource files with target locale characters, enabling developers to test that all UI strings have been externalized, characters are properly rendered, fonts work properly and UI layouts expand as needed based on language requirements. We work with your team to make sure testing goes smoothly so that your product works exactly as expected.

Ongoing Internationalization Support

To support internationalization as an ongoing requirement for all new product development, Globalyzer can be used in command-line mode as an automated process, measuring and reporting on any new internationalization issues that may be inadvertently introduced into code. Furthermore, our internationalization architectural documents serve as an important design reference for locale support for your product lifecycle.

Please to discuss your next project.

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *