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.
