Note: Most of this has been integrated into Globalize and the local dataview (see Grid-SPF).

The Type feature handles detecting, validating, parsing and serializing various data types. One purpose is to enable type-specific sorting and filtering, like currencies or dates.

Implementations for dates and numbers should delegate to the jquery-global plugin.

Open issues:

How should type detection handle cultures? If the culture of a type is unknown, we'd have to try parsing a value as date and number in all cultures. Even that could lead to bad results, when various cultures have similar formats.
How to detect currencies? If parseFloat can produce a result, it can be both a currency and a number. Checking for the existence of a currency symbol works only when the culture is known. Even then there is the unsolved problem of formatting foreign foreign currencies. For example, Yen should never be displayed with decimal places, independent of the current culture.
How to detect time with parseDate?
Do we need type detecton for boolean? What should that look for?
Is there something Type should do we for Lists? Or can we remove that from the list below?
What is a good algorithm for finding a good match? How many rows to check, how to merge inconsistent results?
For a future datepicker rewrite (could be part of Stage 3 - custom inputs) we need to ensure that calendar support in jquery-global is good.

Need to check if non-gregorian calendars are already implemented or can be added. Keith Wood's calendar support is a good reference.

Data types to work with:

String

normal sort using built-in string comparisons

Number (Integer, Decimal, Currency)

parse to number, e.g. remove currency symbol to be able to sort as number
use Globalization for parsing

Date

parse to number (timestamp)
use Globalization for parsing

Time

parse to number (timestamp with normalized date, e.g. at 1970-01-01)
use Globalization for parsing

Boolean

(?) List

Allow passing in multiple values for mutliple select list or the like. (passing delimiter might be of value for non-standard lists, perhaps even array sets)

In general sorting needs to have the value parsed to a number, otherwise will just sort as string.

Filtering can have different options based on the type:

String

exact match
contains match
starts/ends with match
Select/Enumeration if only a limited set of values are available

can be a multi-select

Boolean

true or false

Number, Date, Time

exact match
greater then
lesser then
range
input could be restricted if min or max or both values are known, e.g. using a slider
can use a Datepicker for Date
need to define whether any range is in- or exclusive

Demo with sorting and filtering

http://view.jqueryui.com/grid/grid-type/type.html

Demo with sorting, using the current grid implementation with underlying data model

http://view.jqueryui.com/grid/grid-datamodel/datasort.html

Demo for type detection

http://view.jqueryui.com/grid/grid-type/detection.html

// some olde stuff from dark places of the wiki:

// TODO review and integrate or remove

Use cases:

Set the locale info for all plugins prior to creating any (before document ready) (might be the case that the dom sets the locale e.g. <html lang="en">)
Change locale for all plugins after creation and have them refresh.
Change locale for a single plugin after creation and have it refresh (is this an actual use case?, Yes I have this use case where I have a page with serveral languages on it.)

Requirements:

support localization of the following types

Monetary
Non-monetary numeric
time
date
standard messages, yes/no, close
numeral representation. Languages such as Hindi and Arabic use different characters to represent the digits 0-9. For example, the digit 9 is written as ९ in Hindi.

Formatting information for a locale can be centrally stored and not split between different plugins
i18n cannot be a dependency for jQuery UI widgets. widgets should work properly without any localization.
Must be able to mark strings so that a parser like xgettext can extract translatable strings for external translation.
Support different translation contexts to support instances where the same word has very different meanings in two different parts of the application and may translate to two different words in a given language. This article explains the issue better.

Goals:

Create a full i18n system that supports all locale-related info.
Don't require any extra knowledge/overhead to incorporate i18n into a plugin.

References:

Locales and localization in the GNU C Library

GNU Gettext Utilities

I18n in rails

i18n javascript helper to use the rails translations

How Google Chrome extensions handle i18n