MochiKit.I18n -- proposed new module for internationalization

Skip to first unread message

Per Cederberg

Jan 10, 2011, 5:38:55 AM1/10/11
Since I found the MochiKit.Format.formatLocale() function too limited,
I hacked up a new MochiKit.I18n module:

It is backwards compatible and adds locales for most languages on
earth (data derived from Wikipedia and Google Closure sources). At the
moment it only contains numeric formatting information, but can be
extended with currency and datetime formatting information if needed.

My intention is to include this in the default MochiKit 1.4 tree and
update the MochiKit.Text module to properly support the number
formatting specified in these locales (some are not currently

Please let me know if you have any issues with this.



PS. Pasting in the source rst docs below to give a clue as to how it
is supposed to work.



MochiKit.I18n - internationalization, localization and globalization



assert( locale().decimal == "." );
assert( locale("sv_SE").decimal == "," );


This module contains numeric localization information for most languages
and regions on earth. Actual text formatting lives in other modules (such
as :mochiref:`MochiKit.Text`).


- :mochiref:`MochiKit.Base`


Locale Names
MochiKit uses IETF language codes [1] to identify a locale, e.g.
``"en_US"``. The locale database also supports the use of previously
unknown locale identifiers by creating a new locale based on the
language code or the default locale. A number of built-in locale
identifiers are also supported:

| Language | Description |
| ``system`` | The built-in system locale. It is identical to a |
| | ``"en_US"`` locale for backward compatibility. |
| ``user`` | The user locale, as reported by the browser. This |
| | points to a specific language locale (or the |
| | ``"system"`` locale.) |
| ``default`` | The default locale, used when no language code is |
| | provided. This points to the ``"system"`` locale by |
| | default. |

The default locale is modified by accessing the ``MochiKit.I18n.LOCALE``
cache of resolved locale objects:


MochiKit.I18n.LOCALE["default"] = locale("user");

Locale Objects

The locale objects returned by :mochiref:`locale()` and stored in the
``MochiKit.I18n.LOCALE`` cache all have the following properties (some
inherited through the prototype chain):

| Name | Description |
| ``decimal`` | The decimal dot character. |
| ``separator`` | The thousands grouping character. |
| ``separatorGroups`` | The size of thousands groups (from |
| | right to left). Repeats when exhausted. |
| ``percent`` | The percent character. |
| ``permille`` | The permille character. |
| ``plus`` | The plus sign character. |
| ``minus`` | The minus sign character. |
| ``signAtEnd`` | The boolean sign at end of string flag. |
| ``infinity`` | The infinity character. |

API Reference



Returns the locale object corresponding to ``spec``. The locale
object returned contains formatting and localization information
that is used when displaying data in non-English languages (see
description above for details).

Note that the cached locale database entry is returned, so any
modifications to this object will affect other calls.

The optional ISO/IETF language code [1] or an object to merge
with the default locale. If ``spec`` is omitted, the default
locale is returned. If ``spec`` is not recognized or is not a
string, a custom locale will be created (based on the default

Available in MochiKit 1.5+

See Also

.. [1] IETF BCP 47:

Bob Ippolito

Jan 11, 2011, 8:56:41 AM1/11/11
to Per Cederberg,
This is pretty cool, something I always imagined that I might do if I
were doing this kind of localization. We've only done en and zh at
Mochi, so haven't needed anything outside of the system format.

> --
> You received this message because you are subscribed to the Google Groups "MochiKit" group.
> To post to this group, send email to
> To unsubscribe from this group, send email to
> For more options, visit this group at

Fredrik Blomqvist

Jan 11, 2011, 6:59:15 PM1/11/11
to MochiKit
Before I noticed this thread I and Per exchanged couple of ideas

Summary: both Per and I have had a look at Google Closure i18n module.
comprehensive coverage.
An upcoming (Microsoft sponsored) jQuery-glob lib also seems very
promising, better calendar support for example. It's available in a
non jQuery version here (nice move!):
Perhaps simply add a thin wrapper (using Per's interface) for

// Fredrik

Per Cederberg

Jan 28, 2011, 5:45:17 AM1/28/11
to MochiKit
Once again, the jQuery-route seems to be the way to go. I'll abandon
my dev branch for now.



Fredrik Blomqvist

Feb 4, 2011, 5:36:09 AM2/4/11
to MochiKit
For reference, I noticed the official(?) jQuery version of the glob-
lib resides here:
For some reason the "nje" and "jQuery" version don't link to each
other, rather a manual fork.
The jQuery version has dropped the lib-neutral support but is still
very close to "nje", it currently seems to be more active, has unit-
tests etc. But at time of writing this the actual code- and doc-diff
is just couple of minor fixes and tweaks.

Also, to clarify, one thing that's not included in jQuery-glob but
included in Closure i18n, is timezone detection and handling (thought
not the complete offset listing).

Well, I'm currently evaluating this in an actual app, I'll see what I
// Fredrik Blomqvist

On Jan 28, 11:45 am, Per Cederberg <> wrote:
> Once again, the jQuery-route seems to be the way to go. I'll abandon
> my dev branch for now.
> Cheers,
> /Per
> On Wed, Jan 12, 2011 at 00:59, Fredrik Blomqvist <> wrote:
> > FYI.
> > Before I noticed this thread I and Per exchanged couple of ideas
> > @github.
> >
Reply all
Reply to author
0 new messages