I began mandating an XML solution utilizing one central SWF that reads a localized XML file with translations based on the visitor’s locale. Bloating due to embedded character sets is controlled by embedding only the standard Western European uppercase, lowercase, numerals and punctuation sets plus an extra locale-specific string of characters:
{|}~‘’¡¢£¤¥¦§¨©ª«¬­®¯°±²³´µ¶•¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿł

While this solution works well for Western European locales we’re now moving into Cyrillic and Chinese. There are a couple of options that I’m mulling over to address the issue:

1. Use a separate SWF for each character set. One for Western European, one for Cyrillic, one for Chinese, etc.
2. Unembed fonts for every non-Western European character set. This means throwing custom fonts away and setting all dynamic text fields to _sans for all non-Western European locales. An uglier solution than the first but easier to maintain since I’ll only have two versions of each swf.

Another issue we run into time and time again is our vendors consistently whining about which font to use. I honestly can’t believe that we’re the only company doing this yet vendors don’t seem to possess a Unicode font list that includes any font other than Comic Sans. Ugh, I can’t tell you how sick I am of seeing that font!

So my questions to you, my faithful visitors: How do you address the issue of localization? Do you use multiple SWFs? One SWF with every character set imaginable embedded in it? One SWF with no embedded fonts (_sans)?

And which fonts do you use for localization? Is there some super secret site with true Unicode fonts out there? I’ve seen plenty of fonts that claim to be Unicode but always seem to fall short of that claim.

There has to be a good solution out there somewhere….right?

-rG