Project Fluent is a localization paradigm designed to unleash the expressive power of natural language translations.
==Background==Software localization has been dominated by an outdated paradigm: the translation is just a dictionary of strings which map one-to-one to the English (en-US) copy. This paradigm is unfair and limiting to languages with grammars more complex than English. For any grammatical feature not supported by English, a special case must be added to the source code, leaking logic into all translations. Furthermore, creating good UIs which depend on multiple external arguments is hard and requires the developer to understand the grammar of the languages the product targets. ;Goals*Design a DSL for creating expressive translations which can depend on many internal and external arguments.*Design a low-level API for parsing and formatting translations which keeps localizations isolated from each other.*Create a reference implementation which can be used to build localization frameworks. ;Non-Goals*Create a new localization framework.*Solve IO for all platforms. ==Design Philosophy==Localization is an essential part of the user's experience. The localizers should have control over the translation and be able to adapt it easily to the circumstances and external arguments. Simple things are simple and complex things are possible. The syntax used for describing translations is easy to read and understand. At the same time it allows, when necessary, to represent complex concepts from natural languages like gender, plurals, conjugations, and others. The syntax is designed for reading first, editing second, writing from scratch last. A localizer not familiar with it should be able to write their own translation by looking at other translations in the file and copying-and-pasting. The syntax should allow good error recovery: an error in one message should not break the whole file and should resume normal parsing as soon as possible and with as few losses as possible. Each language is isolated and the localization logic of one language doesn't leak into other other languages nor into the source code. Translations are objects with values and additional data which can be mapped wiki moved to attributes of UI widgets and components. The project builds on top of established resources like Unicode, ICU and CLDR. ==Project Pillars== The intended outcome of Project Fluent is a syntax for describing translation resources and a low-level API for formatting translations into strings. * [https://github.com/projectfluent/syntax Syntax specification]* Requirements and good practices for API implementations* [https://github.com/projectfluent/fluent.js Reference implementation in JavaScript]* Implementation in Python* [https://github.com/projectfluent/fluent-rs Implementation in Rust] ==Roadmap== ===2017 Q1=== ;Main goals* Establish Fluent as a separate project ;Objectvies* Update the FTL syntax* Create a project hub (www, github, wiki)* Release a standalone fluent.js implementation* Publish parsers in JS and Python for tools' use* Reach out to a small number of industry experts* Reach out to a small number of framework authors* Publish an updated version of l20n.js which uses fluent.js* Publish an early version of the Rust implementation ===2017 Q2===;Main goals* Improve localizers' experience* Design the HTML integration ;Objectives* Design UI for localization authoring tools (e.g. Pontoon)* Improve the syntax guide and create more demo-able examples* Add a layer on top of fluent.js which handles language negotiation and resource fallback* Integrate with DOM via MutationObservers* Implement [https://github.com/l20n/spec/blob/master/dom-overlays.markdown DOM overlays]* Integrate with React* Reach out to more external parties ==Relation to L20n==Project Fluent is a spin-off from [[L20n]], a localization framework developed by Mozilla. It only consists of the low-level internals of L20n. By releasing the foundation of L20n as a separate project we hope to enable more organizations to use it. Project Fluent implementations aim to be: atomic, synchronous and pure (no IO). L20n (and L20n.js specifically) is a bundled deal. If you buy into it, there are many things that change: the localization happens on the client side and is async, it is bound to DOM and uses a new file format; the way you make your app localizable is different too. If you’re developing a web application, you likely already have some way of working with the DOM and you’re using an opinionated framework to stay sane. L20n adds a layer on top with its own opinions and paradigms. By decoupling Project Fluent from the rest of L20n’s bundled deal, it will become easier for external parties to adopt it. And we don’t even have to actively try to convince them. We’ve already seen interest from Java, C# and Rust developers. We also know that ICU is interested in revising MessageFormat. With FTL, we can tap into this interest without bringing the entire DOM and async API baggage along.
