I've published fluent-react 0.3.0 today. This version is not
compatible with the previous ones.
The messages prop passed to LocalizationProvider should now be an
iterable of MessageContext instances in order of the user's preferred
languages. The MessageContext instances will be used by Localization
to format translations. If a translation is missing in one instance,
Localization will fall back to the next one.
In its simplest form, the messages prop can be an array:
function generateMessages(currentLocales) {
return currentLocales.map(locale => {
const cx = new MessageContext(locale);
cx.addMessages(MESSAGES_ALL[locale]);
return cx;
});
}
<LocalizationProvider messages={generateMessages(['en-US'])}>
…
</LocalizationProvider>
In order to avoid having to create all MessageContext instances for
all locales up front, it's recommended to make the messages prop an
iterator. The Localization class will iterate over it (memoizing the
items it yields) in case fallback is required.
function* generateMessages(currentLocales) {
for (const locale of currentLocales) {
const cx = new MessageContext(locale);
cx.addMessages(MESSAGES_ALL[locale]);
yield cx;
}
}
<LocalizationProvider messages={generateMessages(['en-US'])}>
…
</LocalizationProvider>
This new design of the LocalizationProvider requires a little bit of
work from the developer. The messages iterable needs to be created
manually. This is intentional: it gives the most control to the
developer with regards to the following three areas:
- translations - the developer decides where translations are stored
and how they're fetched,
- language negotiation - the developer decides which factors are
taken into account for the purpose of the language negotiation, as
well as how exactly it's being done. This allows to store the user's
preference in cookies, localStorage or a server session. I recommend
fluent-langneg for the actual negotiation.
- custom extensions - the developer can pass options to the
MessageContext constructor to configure its behavior or to define
functions available to translations.
In the future we might end up providing ready-made generators of the
messages iterable for the most common scenarios.
One limitation of the current design is that in asynchronous
scenarios, all translations (including any fallback) must be fetched
at once before <LocalizationProvider> is rendered. In the future we
might be able to allow async fetching of fallback locales (possibly
using async generators).
See the README for more information and examples of use:
https://github.com/projectfluent/fluent.js/tree/bd10187207d16a9c66e1acc10230e083fcab1dca/fluent-react
All examples have been updated to use the new API:
https://github.com/projectfluent/fluent.js/tree/bd10187207d16a9c66e1acc10230e083fcab1dca/fluent-react/examples
_______________________________________________
tools-l10n mailing list
[email protected]
https://lists.mozilla.org/listinfo/tools-l10n
