QLocale: It's about time (and dates, and languages, and ...)

One Application, Many Locales

One of the goals of Qt is to make it easy, or at least easier to port from one operating system to another. Windows moving to Linux desktop? Sure.  Macintosh OS X to Symbian? Ok.

What about going from Norway to Germany? Australia to the US of A? Is there any reason that this shouldn't be nearly automatic? While there are a number of details to be aware of, The QLocale class tries to encapsulate many of these.

The reason I'm bringing this up is that QLocale has some shortcomings. While this isn't new, a few use cases have come up recently that highlight the issue. These cases have been accompanied by pointers to other locale data implementations. One example is the MeeGo Touch MLocale class. Another is the Symbian localization APIs. It would be nice to provide some of these features on all Qt platforms.

Quantifying the Problem

We've come up with a short list of things that are missing from QLocale, in no particular order.

• Currency
• Collation
• Writing script
• Numeral script
• Calendar
• Work week days
• First day of the week
• 24 hour time format
• Time zone
• Phone number format
• Language endonym

Additionally, we've been asked about mixed locales. To illustrate: I'm sitting here in Norway writing using US English rules, but when I look up the location of the nearest grocery store, I want the distance units to be in kilometers. The locale database built into Qt doesn't have an en_US for some things, *_NO for others locale. MeeGo Touch divides the locale into a number of categories. This division brings up a question: Given the ability to go from a locale (en_US, for example) to the handling of a particular piece of data (the date, to continue), does Qt need to include the ability to reverse the operation? If I know that it's January 1, 2011, is knowing that this is an en_US formatted date important?

Another issue raised is the value of the built-in locales in Qt. Are these useful, or should Qt rely on the operating system's knowledge of locales? Should the codeset and modifiers documented be supported in a meaningful manner?

Planning a Solution

The thought I want to leave you with is: What do you need from Qt's locale support? Validation or rejection of the features discussed here are encouraged. And if I've missed something, please speak up.