Integrating Fluent — Use Cases
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.
Solution: fluent in JavaScript.
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.
Solution: fluent-langneg in JavaScript.
Problem: Your project supports a large number of locales many of which are not well supported natively by the browsers or the OS.
Solution: fluent-intl-polyfill in JavaScript, or the more complete Intl.js polyfill.
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 fluent-react.
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.
Solution: None yet. Fluent is designed to be agnostic with regards to the localization cycle and can be used with any process. We'd like to see the ecosystem of tools around Fluent grow organically. We've created fluent-syntax in JavaScript, python-fluent in Python and fluent-rs in Rust to provide the building blocks.
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.
Solution: Mozilla develops Pontoon which is a beautiful and usable web-based translation tool. Fluent support in Pontoon is on the way.