Investigate implementing an ECMA 402-based internationalization library

[steveklabnik]

Issue by alexcrichton
Wednesday May 28, 2014 at 18:11 GMT

For earlier discussion, see rust-lang/rust#14494

This issue was labelled with: A-libs, P-high in the Rust repository

---

We have been told that internationalization is pretty standardized at this point on the web and many languages are starting to follow along. The authoritative spec for this is located here, and it sounds like we shouldn't deviate from that spec much (as it's what everyone is expecting).

Nominating, but I do not believe this is a 1.0 issue.

[listochkin]

I actually attempted to start work on this as part of my learning Rust. I wasn't successful at that time but would like to get back to this idea soonish.

[mrhota]

@steveklabnik @alexcrichton any thoughts on why this ECMAScript proposal is the preferred model for an i18n API in Rust instead of, for example, ICU, Java, or C#?

The idea of implementing an ECMAScript API in Rust never occurred to me.

[mastodonfarm]

The 2nd edition of ECMA-402 was published in June 2015:

Web
PDF

[jan-hudec]

I'd like to take a stab on this, converting the locale crate (it is basically useless at the moment and that is the most suitable name).

@listochkin, do you have remains of your attempt anywhere for inspiration?

@mrhota, the adding of toLocaleString method (in Rust conventions it will be to_locale_string) to the types that have locale-specific formatting, via trait, seems like the correct Rust way, following the suit of many existing ToSomething traits and to_something methods.

However, there will have to be some differences. I have not read the ECMA-402 standard to as much detail, but:

• It seems to pass around locale as just names everywhere. I would prefer passing objects.
• The formatting, and parsing, functions need to be actually implemented on such locale object or its subobjects (C++'s std::locale::facet style)

I am also not sure about the NumberFormat and DateTimeFormat objects. I thought just the TR#35 patterns should be enough (they should be able to define everything needed) and it would leave smaller compatibility surface. However, once we add a feature to the pattern, we have to support it anyway and the we can add setters to the pattern object just fine and the fields don't have to be exported, so we can add features without breaking compatibility just fine.

And with an impl ToNumberFormat for str there would be no inconvenience in the common use-case.

[mrhota]

@jan-hudec I'll help with this effort. I'm excited someone else has an interest in this!

I gather that the desire here is to have a library inspired by this spec, since a Rust "implementation" would be ... strange and unidiomatic.

[jan-hudec]

Thank you, @mrhota. First thing will be to come up with reasonable design and name things.

My key requirement is, that formatting for new types can be easily defined. So we will have a trait, similar to Display, but only one and taking a formatting specification, because localization substitutes to dynamic strings, so compile-time checking like std::fmt is not possible.

Rust already uses separate types for times, so time formatting will be triggered by using them and I want similar approach to money, i.e. instead of passing a number and format string indicating monetary format you will pass something like 5 * USD (or 2.5 * EUR or 22 * CZK etc) and that will trigger money formatting, including comparing the currency to the local one and fetching suitable symbol if available (so 5 * GBP will come out as £5.00 is en_GB locale, but as 5.00 GBP in most others.

I also often work with other kinds of dimensional quantities. CLDR contains unit names and abbreviations for various locales, but I haven't seen it integrated in any localization library. And I don't want to integrate it either. I just want to make it easy for application that wants it to extract the necessary bits from CLDR, store it in its translation catalogue or somewhere, and define appropriate formatting for its dimensional quantity type, so it can format 5000 * metre with format ###@@ and get 5.0 km back.

[mrhota]

ECMA-402 is a good place to start, then. it's suitably abstract for a starting point, and I think we can probably arrive at a reasonable first-pass design for i18n components (i.e. locale objects) by "rustifying" (oxidizing?) the basic string stuff from the spec. By the way, someone else "owns" the i18n crate name on crates.io. I was thinking either get that person involved so we can use the name, or go with "Intl", like the spec.

[jan-hudec]

Look at the referencing issue (rust-locale/rust-locale#7). I've put some outline (without much names yet) already.

Regarding i18n, I think locale, as the traditional name, is better for this. The backends will probably get long names, since they will be mostly internal matter and I was thinking about msgfmt or message_format for the formatting layer and either gettext or intl (because the gettext runtime part is called libintl) for the gettext component.

[jan-hudec]

The more I think about this, the less I see ECMA-402 as particularly reasonable inspiration for this. I have done internationalization support in work projects, have a pretty good idea of features it should have and I don't see them in the JavaScript version. The C++ locale seems like much better inspiration.