On Sun, Feb 26, 2017 at 6:04 PM, Staś Małolepszy <[email protected]> wrote:
> 3. Fetching translations > > Right now, fluent-react's LocalizationProvider takes a > `requestMessages` prop which is a function returning a promise. I'd > like to simplify this and use a pattern that I think is common in > React: use wrapping and lifecycle methods to fetch the translations > any way you want. I went ahead and removed `requestMessages` in favor of a simpler API: LocalizationProvider now takes messages as a prop. The task of fetching translations asynchronously is now in developers' hands which allows much more flexibility. See https://github.com/projectfluent/fluent.js/blob/master/fluent-react/examples/async-messages/src/l10n.js#L25-L55 for an example code. If you npm install fluent-react, version 0.1.0 has this new API: https://github.com/projectfluent/fluent.js/blob/master/fluent-react/CHANGELOG.md#fluent-react-010 > There's also a question of runtime fallback. What should happen when > a translation is missing in the current language? We could make > LocalizedElement request the translation asynchronously from > LocalizationProvider, although that might lead to having a lot of > Promises in the running code. I'd need to measure the performance > impact of such approach. It could be introduced later, too, available > as a flag on LocalizationProvider (e.g. runtimeFallback={true}). I'm planning to write an experimental AsyncLocalizationProvider which uses a Promise per LocalizedElement. I'd like to test the performance cost of such an approach. In L20n.js we introduced an optimization: we'd collect identifiers first and then use a single Promise to format all of them. I'm not sure how to do this right in React right now. > Another alternative is to make this a responsibility of the build > setup: before publishing, any translations could be merged with the > default language to fill in the gaps. For even better support of > non-standard fallback orders (i.e. not falling back directly to > English), ServiceWorkers could be used to perform the merging > "build-step" for translations. Once I've written the FTL serializer in JavaScript, I'll publish a tool to merge incomplete localization with more complete ones. Expect more news by the end of this week. _______________________________________________ tools-l10n mailing list [email protected] https://lists.mozilla.org/listinfo/tools-l10n
