Localisation support in legacy browsers is poor. Originally, this was due to phrases in the ECMAScript language spec that look like this:
Number.prototype.toLocaleString()
  Produces a string value that represents the value of the Number formatted according to the conventions of the host environment's current locale. This function is implementation-dependent, and it is permissible, but not encouraged, for it to return the same   thing as toString.
  Every localisation method defined in the spec is defined as "implementation-dependent", which results in a lot of inconsistencies. In this instance, Chrome Opera and Safari   would return the same thing as .toString().   Firefox and IE will return locale formatted strings, and IE even includes a thousands separator (perfect for currency strings). Chrome was recently updated to return a thousands-separated string, though with no fixed decimal.
  For modern environments,   the ECMAScript Internationalization API spec, a new standard that complements the   ECMAScript Language spec, provides much better support for string comparison, number formatting, and date and time formatting; it also fixes the corresponding functions in the Language Spec. An introduction can be found here.   Implementations are available in:
  ·          Chrome 24
  ·          Firefox 29
  ·          Internet Explorer 11
  ·          Opera 15
  There is also a compatibility implementation, Intl.js,   which will provide the API in environments where it doesn't already exist.
  Determining the user's preferred language remains a problem, since there's no specification for obtaining the current language. Each browser implements a method to obtain   a language string, but this could be based on the user's operating system language or just the language of the browser:
// navigator.userLanguage for IE, navigator.language for others
var lang = navigator.language || navigator.userLanguage;
  A good workaround for this is to dump the Accept-Language header from the server to the client. If formatted as a JavaScript, it can be passed to the Internationalization   API constructors, which will automatically pick the best (or first-supported) locale.
  In short, you have to put in a lot of the work yourself, or use a framework/library,   because you cannot rely on the browser to do it for you.
  Various libraries and plugins for localisation:
  ·          Mantained by an open   community (no order):
  ·          Intl.js -   a compatibility implementation of the Internationalisation API
  ·          i18next (home)   for i18n (incl. jquery plugin, translation ui,...)
  ·          numbro.js (home)   (was numeral.js (home))   for numbers and currency
  ·          L10ns (home)   tool for i18n workflow and complex string formatting
  ·          jQuery Localisation (plugin) (home)
  ·          YUI Internationalization support
  ·          jquery.i18Now for   dates
  ·          browser-i18n with   support to pluralization
  ·          counterpart is   inspired by Ruby's famous I18n gem
  ·          jQuery Globalize jQuery's   own i18n library
  ·          Others:
  ·          jQuery   Globalization (plugin)
  ·          requirejs-i18n Define   an I18N Bundle with RequireJS.
0 件のコメント:
コメントを投稿