7个不稳定版本

0.14.1 2024年5月5日
0.14.0 2023年12月13日
0.13.0 2020年5月6日
0.12.1 2020年1月29日
0.11.1 2019年11月19日

#39 in 国际化(i18n)

Download history 35152/week @ 2024-05-04 33466/week @ 2024-05-11 30151/week @ 2024-05-18 34930/week @ 2024-05-25 32837/week @ 2024-06-01 33501/week @ 2024-06-08 31739/week @ 2024-06-15 30656/week @ 2024-06-22 31036/week @ 2024-06-29 35071/week @ 2024-07-06 36879/week @ 2024-07-13 36562/week @ 2024-07-20 37611/week @ 2024-07-27 39375/week @ 2024-08-03 39384/week @ 2024-08-10 31510/week @ 2024-08-17

153,123 每月下载量
210 个库(17 直接)中使用

Apache-2.0

21KB
223

Fluent LangNeg

Fluent LangNeg 是一个用于语言和地区标识符协商的库。

crates.io Build Status Coverage Status

简介

这是 Project Fluent 的一部分 fluent-langneg 库的 Rust 实现。

该库使用 icu-locid 来检索和操作 Unicode 语言和地区标识符。该库提供在地区列表之间协商的算法。

用法

use fluent_langneg::negotiate_languages;
use fluent_langneg::NegotiationStrategy;
use fluent_langneg::convert_vec_str_to_langids_lossy;
use fluent_langneg::LanguageIdentifier;

// Since langid parsing from string is fallible, we'll use a helper
// function which strips any langids that failed to parse.
let requested = convert_vec_str_to_langids_lossy(&["de-DE", "fr-FR", "en-US"]);
let available = convert_vec_str_to_langids_lossy(&["it", "fr", "de-AT", "fr-CA", "en-US"]);
let default: LanguageIdentifier = "en-US".parse()
    .expect("Parsing langid failed.");

let supported = negotiate_languages(
  &requested,
  &available,
  Some(&default),
  NegotiationStrategy::Filtering
);

let expected = convert_vec_str_to_langids_lossy(&["de-AT", "fr", "fr-CA", "en-US"]);
assert_eq!(supported,
            expected.iter().map(|t| t.as_ref()).collect::<Vec<&LanguageIdentifier>>());

有关更多示例,请参阅 docs.rs

状态

根据 fluent-langneg 测试语料库的实现是完整的,这意味着它按预期解析、序列化和协商。

协商方法可以操作 LanguageIdentifierLocale 的列表。

剩下的工作是在通往 1.0 的道路上积累使用经验,添加更多测试,并确保正确处理错误输入。

兼容性

API 基于 UTS 35 中对 Unicode 地区标识符 的定义,并旨在根据该定义解析和序列化所有地区标识符。

注意:Unicode 地区标识符与 BCP47 在“语言标签”名称下指定的内容相似,但不同。对于大多数地区管理和协商需求,此 crate 中使用的 Unicode 地区标识符可能是更好的选择,但在某些情况下,如 HTTP 接受头,您可能需要完整的 BCP47 语言标签实现,而此 crate 不提供。

语言协商算法是 Project Fluent 的自定义解决方案,基于 RFC4647

语言协商策略旨在以最有限的数据量尽可能匹配。算法在没有任何数据库的情况下返回合理的结果,但通过有限或完整的 CLDR likely-subtags 数据库可以改进结果。

结果是为Project Fluent选择的一个平衡点,可能与其他语言协商算法的实现不同,这些算法可能选择不同的权衡。

替代方案

尽管Fluent Locale旨在与W3C接受的语种保持接近,但它并不旨在实现W3C推荐的完整行为和某些方面的语言协商策略,例如权重,目前不是目标。

为此目的,rust-language-tags 库似乎是一个更好的选择。

性能

该库被认为已完全优化以用于生产。

开发

cargo build
cargo test
cargo bench

依赖关系

~0.7–1.4MB
~28K SLoC