export default defineConfig({

use icu::locale::{Locale, locale};

use icu::calendar::Date;

const LOCALE: Locale = locale!("ja"); // let's try some other language

`ICU4X` by default contains data for a a wide range of CLDR locales[^1], meaning that for most languages, the constructors can be considered infallible and you can `expect` or `unwrap` them, as we did above.

[^1]: All locales with coverage level `basic`, `moderate`, or `modern` in [`CLDR`](https://github.com/unicode-org/cldr-json/blob/main/cldr-json/cldr-core/coverageLevels.json)

Internationalization is a broad domain and there are many more components in `ICU4X`.

[dependencies]

In your main.rs, you can use all stable ICU4X components for the recommended set of locales, which get compiled into the library.

ICU4X_DATA_DIR=$(pwd)/baked_data cargo build --release

Experimental modules are published in a separate `icu_experimental` crate:

[dependencies]

In your main.rs, you can now use e.g. the `icu_experimental::displaynames` module.

If you wish to generate your own data in blob format and pass it into ICU4X, enable the "serde" Cargo feature as follows:

[dependencies]

If you wish to share ICU4X objects between threads, you must enable the `"sync"` Cargo feature:

[dependencies]

You can now use most ICU4X types when `Send + Sync` are required, such as when sharing across threads.

If you wish to use data generation in a `build.rs` script, you need to manually include the data and any dependencies (the `ICU4X_DATA_DIR` variable won't work as ICU4X cannot access your build script output).

[dependencies]

zerovec = "0.9" # for databake

[build-dependencies]

This example has an additional section for auto-generating the data in build.rs. In your build.rs, invoke the ICU4X Datagen API with the set of markers you require. Don't worry; if using databake, you will get a compiler error if you don't specify enough markers.

The build.rs approach has several downsides and should only be used if Cargo is the only build system you can use, and you cannot check in your data:

* The build script with the whole of `icu_provider_source` in it is slow to build

* If you're using networking features of `icu_provider_source` (behind the `networking` Cargo feature), the build script will access the network

* `build.rs` output is not written to the console so it will appear that the build is hanging

extern crate alloc; // required as my-data is written for #[no_std]

use icu::locale::{locale, Locale};

use icu::calendar::Date;

const LOCALE: Locale = locale!("ja");

fn main() {

let baked_provider = MyDataProvider;

let date = Date::try_new_iso(2020, 10, 14)

.expect("date should be valid");

Unlike `BakedDataProvider`, `BlobDataProvider` (and `FsDataProvider`) does not perform locale fallbacking. For example, if `en-US` is requested but only `en` data is available, then the data request will fail. To enable fallback, we can wrap the provider in a `LocaleFallbackProvider`.

We can then use the provider in our code:

use icu::locale::{locale, Locale, fallback::LocaleFallbacker};

use icu::calendar::Date;

use icu_provider_adapters::fallback::LocaleFallbackProvider;

use icu_provider_blob::BlobDataProvider;

use icu::locale::{locale, Locale, fallback::LocaleFallbacker};

use icu::calendar::{Date, Gregorian};

use icu_provider_adapters::fallback::LocaleFallbackProvider;

use icu_provider_blob::BlobDataProvider;

For a deeper dive into configuring your data providers in code, see [data-provider-runtime.md].

struct CacheKeyWrap(CacheKey<'static>);

fn borrow(&self) -> &CacheKey<'a> {

&Borrow::<CacheKeyWrap>::borrow(self).0

}

use icu::calendar::{Date, Iso};

fn get_current_date() -> Date<Iso> {

Hint: You can use `Default::default()` for the `DateTimeFormatterOptions` argument.

Typically C++ users can build ICU4X by building the `icu_capi` Rust crate, and linking the resultant static library to their C++ application. This crate contains all of the relevant [Diplomat]-generated `extern "C"` declarations, as well as an idiomatic C++ wrapper using these functions.

_We are still working on improving the user experience of using ICU4X from other languages. As such, this tutorial may be a bit sparse, but we are happy to answer questions on our [discussions forum] and help you out_

path = "unused"

[dependencies]

Some of the keys are required by the parser, but won't be used by us.

You can now set features by updating the `features` key in `Cargo.toml`:

Users wishing to use ICU4X on a `no_std` platform will need to provide an allocator and a panic hook in order to build a linkable library. The `icu_capi` crate can provide a looping panic handler, and a `malloc`-backed allocator, under the `looping_panic_handler` and `libc_alloc` features, respectively.