Investigate implementing an l20n-based localization library

[steveklabnik]

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

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

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

---

Part of this issue is only actionable depending on the outcome of #93.

Localization is a very important feature for a language and is often a very difficult system to get right. Previous attempts with format! do not look like they're going to pan out, and it looks like it's possible to implement a high quality localization system purely in a library implementation.

The most likely candidate for being implemented is the l20n spec. This is a new standard coming out of Mozilla for the web which is still in some development, but it has seen deployment on Firefox OS and is planned to be deployed in Firefox. Other projects such as django are also looking into implementing this spec, so there's certainly precedent.

A rust implementation of the l20n spec would be a good solution for our localization efforts, but some finesse would be required to ensure that the library is as easily usable as the JS api itself.

Nominating, but I believe that this is not necessary for 1.0

cc @zbraniecki

[steveklabnik]

rust-lang/rust#14495 (comment) is especially releavnt, as some work was being done on this already.

[shimon1024]

Cf. http://projectfluent.org/

[jibal]

"l20n" is a bizarre term. The usual terms are l10n, short for localization, which has 10 letters between the l and the n, i18n for internationalization, and g11n for globalization.

[White-Oak]

@jibal http://l20n.org/ It's a play of words. Citating https://wiki.mozilla.org/L20n L20n (L10n x 2) is the code name for a localization architecture taking existing approaches to L10n one step further

[jibal]

@White-Oak It's an ill-considered one. l10n, i18n, and g11n make sense and fit an established pattern ... l20n is just dumb marketing junk ... and I've actually seen Rustaceans misuse l20n as if it was the shorthand for "localization". And the l20n details seem to be quite an overengineered mess and a poor fit to Rust. Rust should go with gettext and other established approaches to i18n ... if l20n ever shows any success, Rust can consider adopting it. Unfortunately, Rust is way behind on the important issue of i18n and contains many roadblocks like format strings being statically parsed by the compiler. The chauvinistic inertia against i18n has been overcome by others; hopefully Rust will somehow do the same.

[Diggsey]

It seems weird to say Rust is "way behind" on this issue, when you can perfectly well use gettext-like approaches right now via libraries, but what languages have l10n built right into the language?

I think the premise of this issue is no longer true: we have many new language features since this issue was created, like procedural macros, which mean that l10n can be implemented as a crate without sacrificing syntax or usability. There's no need for it to be a language level feature.

If you think it should be done a particular way, implement it, publish it to crates.io, and maybe if it becomes popular it could join rust-lang-nursery, or be otherwise "blessed" in some way as the recommended way to do l10n. Starting with "we need to make language changes" seems entirely the wrong way to approach this issue.

[jibal]

I didn't even remotely say anything about making language changes. I did mention the problem with format! being implemented in the compiler and only taking static strings. And there's no support in the library for locales. And the compiler's messages cannot be localized. Rust is an ecosystem, and as an ecosystem it's clearly way behind. Saying "you can implement it and maybe if it becomes popular" doesn't change that, it just confirms it.