-
Notifications
You must be signed in to change notification settings - Fork 45
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 also 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 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 pluralization rules stores 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 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 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 XLIFF, 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.
In particular:
We target Fluent Syntax to be offered as a foundation for the future ICU localization data format and ECMA402/W3C localization data format.
We design Fluent API to be a good target for the future ECMA402 Localization API.
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.
We plan to offer fluent-rs as a fully functional localization framework for Rust.
We intend to work with the frameworks communities to develop well fitting bindings and constitute Project Fluent as a referential solution for localization of software developed in those bindings.
At the moment we're targeting the following frameworks:
- React
- Ember
- Django
- Angular
but we're open to work with any interested framework.