Confirmed users
446
edits
User:Waldo/Internationalization API: Difference between revisions
Jump to navigation
Jump to search
User:Waldo/Internationalization API (view source)
Revision as of 22:44, 16 April 2013
, 16 April 2013Add more information
(More fleshing out) |
(Add more information) |
||
| Line 12: | Line 12: | ||
=== Code organization === | === Code organization === | ||
==== ICU ==== | |||
International Components for Unicode is a library implementing collation, formatting, and other locale-sensitive functions. It provides the underlying functionality used in implementing Internationalization. | |||
==== Integration ==== | ==== Integration ==== | ||
The <code>Intl</code> object is integrated into the global object through code in {{source|js/src/builtin/Intl.cpp}} and {{source|js/src/builtin/Intl.h}}. <code>js_InitIntlClass</code> performs this operation when it's called during global object bootstrapping, in concert with various other initialization methods in the same file and in {{source|js/src/vm/GlobalObject.cpp}}. | The <code>Intl</code> object is integrated into the global object through code in {{source|js/src/builtin/Intl.cpp}} and {{source|js/src/builtin/Intl.h}}. <code>js_InitIntlClass</code> performs this operation when it's called during global object bootstrapping, in concert with various other initialization methods in the same file and in {{source|js/src/vm/GlobalObject.cpp}}. There's some particular trickiness here, as the various <code>Intl.*</code> constructors aren't global classes, yet need to participate in the reserved-slot constructor/prototype system used by <code>Object</code>, <code>Function</code>, <code>Array</code>, and so on to implement "using the original value of <code>Object.prototype</code>" and "as if by <code>new Array()</code>" and similar. | ||
==== Self-hosted code ==== | ==== Self-hosted code ==== | ||
| Line 23: | Line 25: | ||
The majority of the self-hosted code implementing Internationalization is in {{source|js/src/builtin/Intl.js}}. This file defines the functions exposed on the various <code>Intl.*</code> constructor functions and the various <code>Intl.*.prototype</code> objects. | The majority of the self-hosted code implementing Internationalization is in {{source|js/src/builtin/Intl.js}}. This file defines the functions exposed on the various <code>Intl.*</code> constructor functions and the various <code>Intl.*.prototype</code> objects. | ||
Internationalization in various cases requires keeping around large data tables: to record the set of supported currency codes, to record language tag (hyphenated strings describing locales, and various options) mappings, and so on. This data lives in {{source|js/src/builtin/IntlData.js}} and is generated by {{source|js/src/builtin/make_intl_data.py}}. This script downloads original (large) plaintext databases, parses them, and extracts in the proper format the data used by Internationalization. | Internationalization in various cases requires keeping around large data tables: to record the set of supported currency codes, to record language tag (hyphenated strings describing locales, and various options) mappings, and so on. This data lives in {{source|js/src/builtin/IntlData.js}} and is generated by {{source|js/src/builtin/make_intl_data.py}}. This script downloads original (large) plaintext databases, parses them, and extracts in the proper format the data used by Internationalization. Updating this static data — which should happen any time the underlying databases receive an update — should be as simple as rerunning the script. | ||
==== Intrinsic functions ==== | |||
Self-hosted code calls into various intrinsics to access ICU functionality. The full list of Internationalization intrinsics is (necessarily) in {{source|js/src/vm/SelfHosting.cpp}}, but the intrinsics themselves are implemented in {{source|js/src/builtin/Intl.cpp}}. | |||
==== Natively-implemented functions ==== | |||
All the constructor functions are implemented in C++ in {{source|js/src/builtin/Intl.cpp}}. | |||
=== Key concepts === | === Key concepts === | ||
... | ... | ||
=== Known bugs and issues === | |||
ECMA-402 says that the supported numbering systems for a locale are (unsurprisingly) locale-dependent. ICU exposes the default numbering system for a locale via a C++ API, but otherwise it pretends any numbering system can be used by any locale. Thus SpiderMonkey's implementation says that the default numbering system is supported (obviously), and it says a handful of common decimal numbering systems are supported. See <code>getNumberingSystems</code> in {{source|js/src/builtin/Intl.cpp}}. If ICU ever provides more comprehensive information here, we should probably use it. | |||
The ICU interface that exposes a locale's default numbering system (see above) is C++, which (see below) means it's not stable. There's an [http://bugs.icu-project.org/trac/ticket/10039 issue] on file to add a C API for this. | |||
=== Other random details === | |||
ICU provides both C and C++ APIs, but only the C API is considered stable. Given that some people reasonably want to use SpiderMonkey with a system ICU, this means we're generally limited to only the stable C API. Unfortunately, this also means we have to hand-roll our own smart pointers for managing ICU resources. | |||