Thursday, October 15, 2015

Myth #15: Because it's all about that 'face

Oh dear, she's back with yet another myth in this never-ending series:
"Internationalization means making the code easily localizable."
The truth is, I'm writing this blog entry for myself.  While some of this is covered by Myth #1 and Myth #9, it is not fully explored.  And I so often have to reference this explanation, I needed a link.  Write another myth, and Bob's your uncle!

Localizability is a part of what I do.  Not even the biggest part.
Localization is not always needed for a product to be perfectly suited to a particular customer.

Here is an example:
An English-speaking South African customer uses a software product written in the US with English as the default user interface.  She has her session set to the South African locale.  The product detects her locale and formats her data accordingly.  Data she has in other charsets besides the default of UTF-8 is recognized and converted for correct processing.  To manage other locale formats, she can set up channels with locale definitions/filters.  Some of the data she is working with is in another language; it is parsed, stored, and retrieved without any corruption.

There is no localization needed here.  But there is loads of internationalization needed.  (This means, yes, there is internationalization needed in products sold only in the US.)

If you force the need for localization to cover basic locale formats, then you will fail in many markets, because often localization only occurs for a very few regions.  With locale issues factored in as automatic, obviously relying on platforms or centralized databases for locale definitions and formats, only language issues need to be considered in localizations.  That way you can have international English, international French, international German, (Spanish is harder, though some companies do an international Spanish), international Mandarin in Simplified Chinese characters, international Mandarin in Traditional Chinese characters - you get the idea.  (I know international language versions are not ideal - but they are a reality for many companies).

Processing character encodings doesn't come under the banner of localizability, either.  Nor do database schema, nor following international standards, nor using industry standard tables and databases.  None of that makes the product localizable.  True, it helps to create an effective localization, but the primary reason for doing all these things is to enable the product to properly handle worldwide data in its processing.  To paraphrase from Myth #1, the primary reason people use software is to do something to data.  If the software can't do that process correctly, then it is not useful.  And it will not be used, no matter what language and locale format the user interface appears in.