Internationalization (I18n) sooner is better!

September 03, 2013

During my work in the Internationalization (I18n) / Localization (L10n) industry worldwide, I have observed a common approach which impacts negatively the efficient international development of software engineering no matter the technology used or the type of business: The lack of information about the importance and necessity of product internationalization (I18N).

software-internationalizationA typical example: a large or medium company decides to access the e-commerce world using a robust web or smart software to increase its quota over the market. A quick decision is taken to hire a strong developer team or delegate the project to a reputable software house to tackle this mission. Main factors in this narrow vision are: strong and stable application, great features, nice layout and user friendly environment. Nothing, about internationalization (I18N)! Common excuses are usually:  not enough time, extra cost or simply I18N can be handled later! These are false pretexts and later will cause real issues technically and financially once the company decides to expand its business to cover other countries with different languages and cultures.

What is Internationalization (I18n)?

Simply defined, I18N is a process to prepare any type of application to display any language for any locale and handle appropriately items such as correct currencies, date formats, numbers and layout (right to left or left to right).

When should internationalization start?

The best practice is to start the process at the beginning of the analysis phase and to continue the process in parallel with the development process on all levels of an application (UI, business, data layers and database).

Why you should NOT delay I18n to a later phase in development?

I18N is do-able later sure, but the internationalization process at this later stage necessities reconstruction of some major parts of the application such as database, data layer, and also front end, third-party controls, scripts etc... This late in the game re-construction of an application to enable it to support language and locales requires extra effort, extra time and extra expenses versus having planned and coded for I18n since the beginning. Addressing I18n later will take an application back several steps and may result in stability issues and certainly results in repeated testing.

Let me give you some simple examples. Comparison: (example of a simple application)

I18N delayed / omitted

I18N included from the beginning

Analysis (mainly requirements)

Analysis(requirements, I18N preparation)

Database development (traditional structure)

DB Development with I18N perspective included

Data Layer based on the above steps

Data layer based on the above steps (including I18N)

Business logic layer based on previous steps

Business logic including I18N approach from above steps

Front end development

Front end development based on I18N rules

Different types of testing

Different types of testing

Beta version

Beta version

Release version

Release version

I18N Required NOW

Application is I18N READY

Re-analyze overall application

N/A

Database partial re-construction

N/A

Data layer adjustment based on the above changes in the database structure

N/A

Business layer adjustment

N/A

Front end I18N adaptation such as externalize all embedded strings to external repository, same adjustments to be done for third-party components, scripts if needed and other adjustments.

N/A

A complete re-testing (all testing types)

N/A

Second beta version

N/A

Second release

N/A

Based on the above comparison, introducing I18N at the beginning of the web or software development cycle can cut time, effort and expenses to almost half in comparison with pursuing application development without I18N but adapted later after the end of development cycle. This impact is even more pronounced for some languages, let's take my native language Arabic for example.

Arabic Language and I18N

Arabic is one of the languages that clearly demonstrates the importance of considering I18N early as one of the main factors in a software development cycle. The process of internationalization and then localization of software into Arabic includes the following mandatory factors:

  • Content should be displayed from right to left
  • Arabic characters should be displayed correctly as they are different then Latin characters
  • Hijri calendar is a must to use instead of the occidental calendar and related manipulation of dates and time formats
  • Sentences length in Arabic could be larger than its equivalent in English
  • Using equivalent currencies based on the Arabic locale (AR-EG: EGP, AR-sa: SAR etc…)
  • Search input in Arabic words and related complexity regarding manipulating search features from database queries for example
  • Validations rules of client input

The above factors are only a few examples of items that could affect seriously ready-made software when there is a need to I18N it to Arabic. But all these complexities can be avoided if I18N is integrated early during the development phase.

In summary, no matter what the target languages are for localization of your software, I18N is a process that enables an application to display and to deal with any language and locale conventions. Once software is I18N enable, adding new languages in the future become very easy, as it will involve mainly translated resource files and assignment of the new target languages to the software without extra work such as re-analyzing, developing, compiling and extensive testing.

Further Localization and Internationalization Resources

You may also benefit by reviewing the following resources on different aspects of localization and internationalization:

To further understand the entire software globalization process, you should download our PDF Software Globalization Guide.

Globalization Partners International helps customers enter new markets by providing comprehensive web localization and translation services into a variety of languages. Free translation quotes can also be obtained from GPI by submitting source files through our Request a Translation Quote.

You may contact GPI at info@globalizationpartners.com or at 866-272-5874 with your specific questions about your target global markets and your project goals.

Category:
Software Translation
Tags:
Software Internationalization, Software localization, localization industry

It’s all Greek to me: A personal look at the multilingual, multicultural experience9 Effective Tips for Spanish Copywriting

Comments

Currently, there are no comments. Be the first to post one!

Contact Us FREE Globalization eBooks Request Demo Request Quote


Ayman is a native Arabic speaker with extensive expertise in Arabic software and website localization. He is a Microsoft Certified professional (MCP) since 2001 and earned several certificates including MCSD, MCAD, MCTS and MCPD. He has over 12 years’ experience in software / websites engineering using Microsoft Programming tools including C#, ASP.NET, SQL Server, Visual Studio and other tools such as HTML, JavaScript, XML, Ajax and others.