internationalization (I18N)<\/a>! Common excuses are usually:\u00a0 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.<\/p>\nWhat is Internationalization (I18n)?<\/h5>\n
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).<\/p>\n
When should internationalization start?<\/strong><\/p>\nThe 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).<\/p>\n
Why you should NOT delay I18n to a later phase in development?<\/strong><\/p>\nI18N 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.<\/p>\n
Let me give you some simple examples. Comparison: (example of a simple application)<\/p>\n
\n\n\nI18N delayed \/ omitted<\/strong><\/td>\nI18N included from the beginning<\/strong><\/td>\n<\/tr>\n\n| Analysis (mainly requirements)<\/td>\n | Analysis(requirements, I18N preparation)<\/td>\n<\/tr>\n | \n| Database development (traditional structure)<\/td>\n | DB Development with I18N perspective included<\/td>\n<\/tr>\n | \n| Data Layer based on the above steps<\/td>\n | Data layer based on the above steps (including I18N)<\/td>\n<\/tr>\n | \n| Business logic layer based on previous steps<\/td>\n | Business logic including I18N approach from above steps<\/td>\n<\/tr>\n | \n| Front end development<\/td>\n | Front end development based on I18N rules<\/td>\n<\/tr>\n | \n| Different types of testing<\/td>\n | Different types of testing<\/td>\n<\/tr>\n | \n| Beta version<\/td>\n | Beta version<\/td>\n<\/tr>\n | \n| Release version<\/td>\n | Release version<\/td>\n<\/tr>\n | \nI18N Required NOW<\/strong><\/td>\nApplication is I18N READY<\/strong><\/td>\n<\/tr>\n\n| Re-analyze overall application<\/td>\n | N\/A<\/strong><\/td>\n<\/tr>\n\n| Database partial re-construction<\/td>\n | N\/A<\/strong><\/td>\n<\/tr>\n\n| Data layer adjustment based on the above changes in the database structure<\/td>\n | N\/A<\/strong><\/td>\n<\/tr>\n\n| Business layer adjustment<\/td>\n | N\/A<\/strong><\/td>\n<\/tr>\n\nFront end I18N<\/strong> 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.<\/td>\nN\/A<\/strong><\/td>\n<\/tr>\n\n| A complete re-testing (all testing types)<\/td>\n | N\/A<\/strong><\/td>\n<\/tr>\n\n| Second beta version<\/td>\n | N\/A<\/strong><\/td>\n<\/tr>\n\n| Second release<\/td>\n | N\/A<\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n 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.<\/p>\n Arabic Language and I18N<\/h5>\nArabic 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:<\/p>\n \n- Content should be displayed from right to left<\/li>\n
- Arabic characters should be displayed correctly as they are different then Latin characters<\/li>\n
- Hijri calendar is a must to use instead of the occidental calendar and related manipulation of dates and time formats<\/li>\n
- Sentences length in Arabic could be larger than its equivalent in English<\/li>\n
- Using equivalent currencies based on the Arabic locale (AR-EG: EGP, AR-sa: SAR etc\u2026)<\/li>\n
- Search input in Arabic words and related complexity regarding manipulating search features from database queries for example<\/li>\n
- Validations rules of client input<\/li>\n<\/ul>\n
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.<\/p>\n 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.<\/p>\n","protected":false},"excerpt":{"rendered":" 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). A typical example: a […]<\/p>\n","protected":false},"author":2,"featured_media":6124,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[11],"tags":[1451,1450,1444],"_links":{"self":[{"href":"https:\/\/www.globalizationpartners.com\/wp-json\/wp\/v2\/posts\/6123"}],"collection":[{"href":"https:\/\/www.globalizationpartners.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.globalizationpartners.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.globalizationpartners.com\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.globalizationpartners.com\/wp-json\/wp\/v2\/comments?post=6123"}],"version-history":[{"count":4,"href":"https:\/\/www.globalizationpartners.com\/wp-json\/wp\/v2\/posts\/6123\/revisions"}],"predecessor-version":[{"id":15965,"href":"https:\/\/www.globalizationpartners.com\/wp-json\/wp\/v2\/posts\/6123\/revisions\/15965"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.globalizationpartners.com\/wp-json\/wp\/v2\/media\/6124"}],"wp:attachment":[{"href":"https:\/\/www.globalizationpartners.com\/wp-json\/wp\/v2\/media?parent=6123"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.globalizationpartners.com\/wp-json\/wp\/v2\/categories?post=6123"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.globalizationpartners.com\/wp-json\/wp\/v2\/tags?post=6123"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}} | | | | | | | | | | | | |
![\"software-internationalization\"](\"https:\/\/www.globalizationpartners.com\/wp-content\/uploads\/2018\/07\/software-internationalization_363x289.jpg\")
<\/p>\n