Changes

Project Fluent is a localization paradigm designed to unleash the entire expressive power of natural language translations. Project Fluent keeps simple things simple and makes complex things 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.

==Why are we doing this?Background==Project Fluent is a spin-off from [[L20n]], a Software localization framework developed has been dominated by Mozilla. an outdated paradigm: It only consists the translation is just a dictionary of the lowstrings which map one-level internals of L20n. By releasing the foundation of L20n as a separate project we hope to enable more organizations -one to use it. L20n the English (and L20nen-US) copy.js specifically) This paradigm is a bundled deal. If you buy into it, there are many things that change: the localization happens on the client side unfair and is async, it is bound limiting to DOM and uses a new file format; the way you make your app localizable is different toolanguages with grammars more complex than English. If you’re developing For any grammatical feature not supported by English, a web application, you likely already have some way of working with the DOM and you’re using an opinionated framework special case must be added 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 dealsource code, it will become easier for external parties to adopt it. And we don’t even have to actively try to convince themleaking logic into all translations. We’ve already seen interest from JavaFurthermore, C# creating good UIs which depend on multiple external arguments is hard and Rust developers. We also know that ICU is interested in revising MessageFormat. With FTL, we can tap into this interest without bringing requires the developer to understand the grammar of the languages the entire DOM and async API baggage alongproduct targets.

:*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.:Create documentation for implementing it in other projects and languages.

:*Create a new localization framework.*Solve IO for all platforms.

Project Fluent encapsulates a lot Each language is isolated and the localization logic of main design axes of L20none language doesn't leak into other other languages nor into the source code.

* Separation Translations are objects with values and additional data which can be mapped to attributes of concerns* Translations-as-an-object (great for UI widgets and components)* More control for the localizers* Better and more-natural sounding translations* Integration with Intl/ICU.

Project Fluent implementations aim to be: atomicThe project builds on top of established resources like Unicode, synchronous ICU and pure (no IO)CLDR.

==StatusRelation 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.

The FTL syntax used in L20n.js as By decoupling Project Fluent from the rest of January 1stL20n’s bundled deal, 2017it 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, will be tagged as version 0C# and Rust developers. We also know that ICU is interested in revising MessageFormat.1With FTL, we can tap into this interest without bringing the entire DOM and async API baggage along.