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 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.
