I have not, generally speaking, been a "flasher" (for the last few years at least!)

by Michael S. Kaplan, published on 2010/02/24 07:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2010/02/24/9968410.aspx


This is not a post about flashing people while telling them how to be more world ready with their code!

This is, however, a post about Adobe's Flash.

Not about the whole Apple/Adobe HTML5/Flash thing that everyone else is writing about that is so controversial.

As fascinating as that may be for some.

For the record, none of my friends at Apple, Adobe, or Microsoft find that stuff to be something fun to engage on, but clearly there are people somewhere having a good time with it. I don't personally know any of them as far as I know.

Anyway, this is about something my friend Mihai at Adobe told me about.

You see, for as long as I have known about/dealt with Flash, what I have found most frustrating was the lack of globalization support.

It drove me nuts, in fact, any time I had to deal with it (some high profile web sites I was helping people with had major issues because of this lack!).

But no longer.

Enter flash.globalization!

This is a really amazing set of classes. Check it out:

Class Description
  Collator The Collator class provides locale-sensitive string comparison capabilities.
  CollatorMode The CollatorMode class enumerates constant values that govern the behavior of string comparisons performed by a Collator object.
  CurrencyFormatter The CurrencyFormatter class provides locale-sensitive formatting and parsing of currency values.
  CurrencyParseResult A data structure that represents a currency amount and currency symbol or string that were extracted by parsing a currency value.
  DateTimeFormatter The DateTimeFormatter class provides locale-sensitive formatting for Date objects and access to localized date field names.
  DateTimeNameContext The DateTimeNameContext class enumerates constant values representing the formatting context in which a month name or weekday name will be used.
  DateTimeNameStyle The DateTimeNameStyle class enumerates constants that control the length of the month names and weekday names that are used when formatting dates.
  DateTimeStyle Enumerates constants that determine a locale-specific date and time formatting pattern.
  LastOperationStatus The LastOperationStatus class enumerates constant values that represent the status of the most recent globalization service operation.
  LocaleID The LocaleID class provides methods for parsing and using locale ID names.
  NationalDigitsType The NationalDigitsType class enumerates constants that indicate digit sets used by the NumberFormatter class.
  NumberFormatter The NumberFormatter class provides locale-sensitive formatting and parsing of numeric values.
  NumberParseResult A data structure that holds information about a number that was extracted by parsing a string.
  StringTools The StringTools class provides locale-sensitive case conversion methods.

Mihai gave me some of the skinny on the internal, and in some ways it is similar to Silverlight as it uses the underlying platform it is running on for a lot of the support (as I talked about Silverlight doing back in blogs like Shine a Little [Silver]Light). Though in the case of flash.globalization, if the platform lacks a solid story then it falls back to ICU. This does not apply to Windows, where the existing support is used.

It supports custom cultures/custom locales!

It is all name based, using the RFC!

Not even the newest version of Office (due out soon?) can say that, and they have an XML-based standard and over a decade of notice about doing that....

And there were other interesting bonuses I found out from Mihai when talking about flash.globalization. Like remember LOCALE_SDECIMAL? Quite a character! Or two. Or three... from the other day? The one that broke the new Windows Calculator and has caused problems for Excel and other parts of Microsoft products?

Well flash.globalization can handle multiple characters in those locale fields like LOCALE_SDECIMAL and LOCALE_STHOUSAND and so forth. In parsing and formatting.

I'll need to check on things like LOCALE_SDATE and LOCALE_STIME to make sure they work too, though I must admit I am optimistic that if there is a bug I won't be fielding questions about whether such things really happen in shipping locales. No offense to people who might be inclined to do that, of course! :-)

Here is another reference if you are hungry for information in it:

The flash.globalization package in Flash Player: Cultural diversity without complexity

Some very cool information here about using it for those who might be interested.

Anyway, thinking about a third party component that is able to consume so much of the functionality that I have been working with, on, in, and around for so long to improve the story on a platform that used to not do any of this is really really exciting!


# Tom on 24 Feb 2010 9:53 AM:

Too bad!!!

Did they understand customer's interest?

We just like platform-independent feature.

# Michael S. Kaplan on 24 Feb 2010 1:00 PM:

Which "they" do you mean? There's a lot of "theys" in this blog! :-)

# Mihai on 27 Feb 2010 12:00 PM:

I guess the complaint was about relying on the underlying OS services.

But we had to choose between what the developers want (platform-independence) and what the end-user wants (consistency with all the familiar behavior, respect for his preferences).

As a developer I want the same result, guaranteed, on all platforms.

But as an end-user I don't care about developers. I don't move between Windows, Mac and Linux, so I don't care about that consistency. But I do move between Flash/AIR/Excel/etc. and I don't appreciate if applications that don't respect my Control Panel preferences.

A tough choice to make.

But we think that in the end our developers also appreciate the experience of the end user more than their own comfort.

Anyway, that this kind of discussion will happen, and we'll explain all decisions, I promise nothing was random (or laziness ;-)

But not on Michael's blog :-)

# Michael S. Kaplan on 27 Feb 2010 1:51 PM:

.Net has the same problems itself -- those who want it to work like the Windows it is on, those who want it act like it does on other platforms....

Pavanaja U B on 22 Mar 2010 10:11 PM:

This might not be a place to ask the question. May be Mihai can answer this: What is the status of Indic/opentype rendering on Flash? AFAIK, it does not.

-Pavanaja

Mihai on 18 Jun 2010 3:48 PM:

It is fine since Player 10.0, released about one and a half year ago.

With that version the Player introduced a new text engine.

But it takes time until all the tooling catches up (think Flash Pro, Flex, others)

The engine adds support for Indic scripts, bidi (Arabic and Hebrew), vertical text (useful for Chinese and Japanese), and advanced typography features for other scripts (including Latin)

If you want to use the engine with older tools, you should download the Text Layout Framework library from labs.adobe.com/.../textlayout.

The tools are also catching up.

Flash Pro in Creative Suite 5 addresses that for designers, and Flex 4 deals with it for programmers.


Please consider a donation to keep this archive running, maintained and free of advertising.
Donate €20 or more to receive an offline copy of the whole archive including all images.

referenced by

2010/06/16 JavaScript's got a whole new ultimate globalization hero

2010/03/02 Seeing double? You're not drunk; you're just running pseudo! (aka Announcement: Pseudo Day!)

go to newer or older post, or back to index or month or day