• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Browse and search Google Drive and Gmail attachments (plus Dropbox and Slack files) with a unified tool for working with your cloud files. Try Dokkio (from the makers of PBworks) for free. Now available on the web, Mac, Windows, and as a Chrome extension!



Page history last edited by Jörn Zaefferer 9 years, 10 months ago

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. 


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


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


Demo for type detection




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

// TODO review and integrate or remove


Use cases: 

  1. 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">)
  2. Change locale for all plugins after creation and have them refresh.
  3. 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.)



  1. support localization of the following types
    1. Monetary
    2. Non-monetary numeric
    3. time
    4. date
    5. standard messages, yes/no, close
    6. 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.
  2. Formatting information for a locale can be centrally stored and not split between different plugins
  3. i18n cannot be a dependency for jQuery UI widgets. widgets should work properly without any localization.
  4. Must be able to mark strings so that a parser like xgettext can extract translatable strings for external translation. 
  5. 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. 



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



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 




Comments (0)

You don't have permission to comment on this page.