To answer the question, we should first talk about L10n first. L10n is the process of adapting a product, application, or document to meet the language, cultural, and other requirements of a specific target market (a "locale"). The abbreviation of L10n comes from the word "Localization" where the first letter is "L" and the last letter is "n" and there are 10 letters in between. The concept of making a system "Localized" is taking an English developed system and allowing it to display (for example) Spanish language text in its place.
 
i18n comes from the word "Internationalization" where the first letter is "I" and the last letter is "n" with 18 characters in between. So, you may ask, isn't internationalization and localization the same? Actually, NO!
 
There is a lot of confusion because these concepts are relatively new as well as the fact that historically systems have been designed in English first and then retrofitted for say French or Spanish. Therefore not only do localized systems require an "effort" to retrofit but even if both languages actually share a common character set they may still be incompatible! Historically, L10n has been done before ever thinking about i18n which is how MOST Insurance Systems are being sold today; IE: they can be retrofitted; however because its "after the fact" it is not only more difficult but it often takes programmers to go through the system as replace or retrofit EVERY text line in the system; and still may have incompatibilities that are hard to test and correct.
 
Conceptually, i18n MUST come first; as internationalization is the process of ensuring a piece of software is actually flexible enough and ready to support multiple potential locales in the first place. No actual language is involved in the i18n process; an application may well never be translated, but if it is properly internationalized then translating it is quite easy (and, more importantly, doesn't require any development or computer skills at all, only knowledge of the target language). Internationalization, then, is making software locale-friendly right from the start.
 
When a system has been designed with i18n in mind - the i18n process has been incorporated into the system in such a way that not only are ALL text representations available to non-developers but the process of adding languages is simply to translate these text sentences and phrases into their correct translations EVEN if the language is in very different character sets for example even languages that are read from right to left!
 
The Quick Silver Systems Mercury Policy and Claims processing system has incorporated i18n into the core so translations to other languages is not only standardized to the i18n standard but the support for ANY language has been built into the product from the ground up. To support a new language simply take the English JSON file which contains every textual message in the system and translate it to the target language. No programmers, and no retro fitting required. NOTE: Some insurance forms and endorsements may ALSO need language updates which are outside of the policy and claims management system - however the Mercury System can support an entirely new language in days rather than the months it would take through retrofitting...
 
Remember if you want superior support, upgrade your system with the latest technologies; OR, If you are looking to expand your product offerings and want to fully automate for 100% web based desktop, tablet, and mobile devices the Mercury Policy and Claims Processing System is ready for the challenge - give us a call and let us demonstrate YOUR rating working in the system in as little as a week!
 
If you found this article interesting, informative, or helpful; please feel free to share...
 
Sincerely, Sean Pitcher - CEO Quick Silver Systems, Inc.
 
overalay

SCHEDULE A DEMO