cldr VS icu4x

Creating this mapping is a manual process, and the link contains the reference for the mappings. To establish this mapping, you can find the necessary information by visiting the link.

One problem I stumbled upon frequently is codebases that did not support localized formats, but just assumed a certain format to use, for example through concatenation.

There are capabilities built into the programming languages, which allow to format numbers, currencies, etc. with a specific locale. There are also great resources [1] out there that provide all kinds of formats and localized names for countries, currencies, etc.

[1] Unicode CLDR: https://github.com/unicode-org/cldr

Small addition: If you need the characters in machine-readable form, the source is the CLDR project. For Portuguese, the XML file is here on Github: https://github.com/unicode-org/cldr/blob/master/common/main/pt.xml

This information is false. en-150 in CLDR does not use this Euro English variant. It's just world English (en-001) with 3 adjustments: 24 hour time, currency symbol after the number and European time zone codes. Source. That's it.

ICU4X has a large priority backlog which are "issues that the team wants to definitely see fixed, but which currently lack resourcing."

this also (probably) means it's safe from LLVM-noalias unsoundness, though it still runs into the same Rust-level unsoundness

Actually, the Rust version also offers multiple modes, see comparison.rs:

It's generated from https://github.com/unicode-org/icu4x/blob/main/provider/datagen/data/segmenter/dictionary_cj.toml, which in turn comes from ICU4C.

The code can be seen at https://github.com/unicode-org/icu4x, I count 193 uses of unsafe, though not all are the keyword, and some are in tests.

We've got an issue filed about noalias UB in Yoke.

As a reference for his expertise: he's part of team that develops https://github.com/unicode-org/icu4x