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 23:19, 16 April 2013
, 16 April 2013Add more details
(Add more information) |
(Add more details) |
||
| Line 25: | 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. Updating this static data — which should happen any time the underlying databases receive an update — should be as simple as rerunning the script. | 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. '''XXX Link to the mailing lists to track to learn when updates occur!''' | ||
==== Intrinsic functions ==== | ==== Intrinsic functions ==== | ||
| Line 33: | Line 33: | ||
==== Natively-implemented functions ==== | ==== Natively-implemented functions ==== | ||
All the constructor functions are implemented in C++ in {{source|js/src/builtin/Intl.cpp}}. | All the constructor functions are implemented in C++ in {{source|js/src/builtin/Intl.cpp}}. These need to call into enough C++ code to create the necessary ICU data structures for it to be worth keeping them in C++. | ||
=== Key concepts === | === Key concepts === | ||
=== Known bugs and issues === | === Known bugs and issues === | ||
| Line 47: | Line 47: | ||
=== Other random details === | === 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 | 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 pointer for managing ICU resources. | ||
Most of the ICU methods indicate errors through an error code outparam. Also, such APIs check the existing value in that outparam before proceeding. Thus a sequence of ICU calls can occur without error-checking right up til the end, where a single <code>U_FAILURE(status)</code> will suffice to handle all errors that might occur. | |||