Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Fluent is designed to be minimalist, modular and composable. It's a low-level toolbox on top of which higher-level abstractions can be built. The Fluent API is simple and unopinionated. It doesn't make many assumptions about the stack it's going to be integrated into. This allows great flexibility and makes Fluent a good choice for many different use-cases.
With time, frequently used boilerplate may become part of Project Fluent, preferably as small independent modules. Some modules may also serve as meta modules and pull other smaller modules together for a more complete solution.
Integrating Fluent into your project will likely require writing some glue code. Because you'll write that code yourself, it has a much better chance of fitting well into the rest of your stack. What follows is an overview of areas which may require consideration. We're trying to offer modular and composable solutions to all of them.
Problem: You need to parse translation resources and format translations to be able to show them in the UI. Formatting may involve interpolating external variables, selecting the right plural form or formatting dates according to the user's locale.
Problem: You need to choose the best language among the ones your project is available in to show to the user, according to the browser preferences the user has set.
Problem: Your project supports a large number of locales many of which are not well supported natively by the browsers or the OS.
Problem: You need to fetch translations dynamically on the client after the language negotiation is done. Or you want to spit translations per-view and load them only when required. Or you need to render one view on the server-side. Or you want to fetch most of the translations asynchronously but bundle the Please wait… UI in all supported languages together with the app so that it's always available. Or… (you get the idea).
Solution: Write your own code. Fluent doesn't provide any IO methods and expects that the developer will supply the proper translations to it. Even the React bindings for Fluent rely on the developer creating a wrapper component for fetching translations. This allows for maximum flexibility.
Problem: You'd like to put your source copy in the source code and then have a script automatically extract it into an updated translation resource.
Solution: None yet, but we're working on designing the extraction from source in
Problem: You'd like to notify localizers when translations require updating or create a build-step which merges each locale's localization files with your source language, thus providing a rudimentary build-time fallback mechanism. Or you'd like to perform a similar fallback optimization in a ServiceWorker which would benefit from knowing the current user's preferred language fallback order.
Problem: You'd like to have a nice tool for localizing Fluent translation files. Your localizers are not developers and they prefer easy-to-use GUI CAT tools.