ICU4X Documentation

The calendrical_calculations crate provides implementations of algorithms from the book Calendrical Calculations by Reingold & Dershowitz (4th edition, 2018).

Its primary purpose is to serve as a dependency for ICU4X, providing the mathematical foundation for calendrical logic used within the ICU4X ecosystem. While primarily intended for ICU4X, it can be used by other projects if needed.

ICU4X measures performance across four primary dimensions to ensure the library remains modular, fast, and slim:

1. Performance: Microbenchmarks located in each component's benches/ directory, currently using wall-time measurements via the criterion framework.
2. Memory utilization: Measuring Peak Memory Utilization and Data/Struct Allocation (Note: memory benchmarks are currently in development).
3. Binary and Data size: Measuring the size of optimized static binaries from the example/ directory and the total size of production ICU4X data payloads.
4. Code coverage: Ensuring data-driven tests provide high coverage (aiming for >90%) of code paths.

litemap provides LiteMap, a simplistic "flat" key-value map implemented using a single sorted vector.

It is designed for small collections where minimizing binary size is a priority. While std::collections::BTreeMap is a more robust general-purpose choice, LiteMap is optimized for scenarios where you want to avoid the binary size overhead of HashMap or BTreeMap and where the collection size is typically small.

ICU4X is a set of modular internationalization components designed for client-side and resource-constrained environments. Unlike traditional ICU (ICU4C/ICU4J) which is optimized for high-performance server environments, ICU4X prioritizes:

• Small, modular, fast, and low-memory code.
• Pluggable locale data to allow for flexible data loading.
• Multi-language availability through bindings or compilation targets.
• Correctness across all languages and locales without structural disadvantage.

The project aims to provide functionality consistent with [ECMA-402], serving as a modern replacement for client-side solutions like Closure i18n and Dart Intl.

ICU4X (ICU for X) is a modular internationalization library designed for resource-constrained environments and modern platforms. It provides components for a wide range of software internationalization needs, drawing from ICU4C/J and ECMA-402, and utilizing data from the CLDR project.

Key design goals include:

• Small and modular code
• Pluggable locale data
• Availability and ease of use in multiple programming languages (including Rust, JavaScript, Objective-C, Java, Dart, and C++)
• Expert-driven implementation to encourage best practices.

ICU4X is a modular Unicode component library designed for modern internationalization (i18n) needs. Its primary goals are:

• Modularity and Composability: Allows client-side and resource-constrained environments to fine-tune the data payload they include, maximizing coverage while minimizing footprint.
• High Performance & Low Overhead: Provides a high-quality i18n API implementation written in a modern language (Rust) with low memory overhead and high runtime performance.
• Robust FFI: Exposes APIs to many target ecosystems via Foreign Function Interface (FFI), reducing maintenance costs for multi-stack environments.
• Flexible Data Management: Offers a powerful system for managing data selection and updates, supporting sophisticated software release models.

The icu_properties_data crate provides the compiled data required by the icu_properties crate. This data is generated from specific upstream sources to ensure consistency with Unicode standards.

Data Generation Sources:

• CLDR version: 48.2.1
• ICU version release: 78.1rc
• LSTM segmenter version: v0.1.0

The icu_locale_data crate provides the data required by the icu_locale crate. This data is generated from specific versions of Unicode and ICU resources, specifically:

• CLDR version: 48.2.1
• ICU version: release-78.1rc
• LSTM segmenter version: v0.1.0

The zerotrie crate provides a data structure for zero-copy storage and retrieval of byte strings. It is specifically optimized for the efficient storage of ASCII strings. In a ZeroTrie, strings are mapped to usize values.

Key characteristics:

• Zero-copy: Designed for efficient retrieval without unnecessary allocations.
• Immutable: ZeroTrie does not support mutation. To modify data, you must convert the trie to and from a LiteMap or a BTreeMap.
• Safety: All runtime lookup code is 100% safe Rust. Unsafe Rust is only used in specific builder scenarios or when implementing certain traits with the zerovec feature enabled.