Fluent and Standards
One of the core design principles for Project Fluent is to align it with currently existing Internationalization Standards like Unicode, CLDR, ECMA402, ICU and W3C LTLI.
That allows Project Fluent to isolate its area of responsibility to handling localization process, and leaving all internationalization related issues to their designated processes and APIs.
Project Fluent is designed with the plan to put its components on the standardization path as well.
Project Fluent follows Unicode Standard in almost all areas. In particular, we follow UTR#17, UTR#31 and Unicode Character Encoding Schemes expecting all of Fluent localization data to be encoded in UTF-8, UTR#35 for LDML (with a few exceptions listed below) and UTR#9 for BiDi handling.
Project Fluent treats CLDR as the reference database for localization data and shapes its APIs to be compatible with the data models from CLDR (and LDML). That means, among other things, that we separate areas of concern between what should be stored as localization data, and what should be internationalization data by looking up at the CLDR tables.
While it's not a hard dependency, if the user will want to bind a different database with Fluent, we expect that this database will be able to provide similar data to what CLDR covers.
For example, Project Fluent pluralization abilities depend on the plural categories defined in LDML and is compatible with the pluralization rules stored in CLDR. Users can compose Project Fluent with other ways to provide pluralization, but we will not aim to directly support multiple intl backends.
We treat ECMA402 API as the primary API reference point and tightly bind our intl bindings to work with ECMA402 APIs.
We see ECMA402 as a good iterative step over ICU that's tailored for the modern Web ecosystem and that makes it a great match for Project Fluent.
In our reference JS implementation, we will expect ECMA402 as a dependency, and in other implementations we will expect similar APIs to be provided.
We do not impose a strong dependency on ICU and we do not expect users to require ICU to use Project Fluent, but
- we put effort into ensuring that Project Fluent compose with ICU well
- we use it as a reference point for designing our APIs
That means that we treat ICU as a reference example for an Internationalization API due to it's great industry backing, tight integration with CLDR, and excellent bindings into multiple programming languages.
For all implementations that do not provide the ECMA402 API directly, we expect to develop thin wrappers around ICU as the easiest way to provide the intl functionality in Project Fluent.
Project Fluent aims to be an answer to the needs of multilingual Web UIs and as such, we intend to compose well with HTML, DOM and other W3C/WHATWG standards.
In particular, we are staying in close sync and follow W3C recommendations for Language Tags and Locale Identifiers, Internationalization Best Practices for Spec Developers and BiDi recommendations.
Project Fluent brings a new paradigm to the layer of software localization and that comes with a set of areas which we propose a different solution to compared to the existing standards and technologies.
We recognize previous localization data formats like MessageFormat and Gettext, but we believe it is necessary for our goals to design a new syntax. The relationship between Project Fluent data format and MessageFormat is documented here.
The core of the Project Fluent stays fairly unopinionated when it comes to localization strategies. We keep it pretty plain and straightforward to bind into different front-end flows. At the same time we focus on developing Project Fluent as a stepping stone toward an opinionated localization strategy proposal designed in Mozilla, codenamed L20n. The relationship between Project Fluent and L20n is documented here.
In relation to the localization strategies, we're designing our own proposal for language negotiation. It is heavily based on RFC4647 with optional use of LDML likelySubtags and additional custom strategies.
We believe this to be necessary for our effort to improve the language fallbacking and improve user experience in non-optimal scenarios (missing or corrupted data etc.).
Project Fluent is going to offer a multi-scenario proposal for localization cycle in the user's project release cycle together with tooling to execute it. We intend to keep it flexible in order to allow for fitting it into different release cycle models, but keep it in line with our paradigm proposal.
We consider the current state of localization tooling, both the translator aiding tools and release management tools to be very limiting. We see it as a major obstacle in the ability to advance the localization frameworks and the quality of software translation itself. We're experimenting with new UI and workflow paradigms that will make working with Project Fluent easier while at the same time allowing for better translations and better software quality.
We target Project Fluent for the future Web Localization proposal. We're designing our APIs and components in a way that allows for easy composition with other Internationalization Standards like ECMA402 and ICU.
At the core of Fluent are the syntax and the formatting spec. The Fluent spec is designed with the following goal in mind: to be offered as a foundation for the future ICU localization data format and ECMA402/W3C localization data format.
fluent.js is the reference implementation of Fluent. It is developed as a polyfill of the future ECMA402 Localization API. fluent-rs is an experiment written in Rust demonstrating the feasibility of implementing Fluent natively in the browser.
Fluent is designed to be minimalist and composable. It's a low-level base on top of which more advanced solutions can be built. Some of them may be considered for standards in the future.
We hope to work with the Web community to design the DOM bindings in a way that will make them a good candidate for the future HTML/DOM L10n Standard. This includes designing a way to localize DOM fragments (with multiple children) in a secure manner which doesn't break event listeners and allows translations to use a a limited set of text-level elements. See L20n's DOM overlays for prior work.
We intend to work with the frameworks communities to develop idiomatic bindings and establish Project Fluent as a viable solution for localization. At the moment we're targeting the following frameworks:
- React
- Ember
- Angular
- Django
We're open to work with any interested framework to create new Fluent integrations.