Stanisław Małolepszy

> Can you explain what resource drain do you have on mind? What experience degradation are you worried about? I'm worried about the cost of providing support to projects which...

Thanks, @zbraniecki, I appreciate your position. > Would it be alleviated if we moved it out of `@fluent` package to, say, `@zbraniecki/fluent-web`? :) A little bit :) I think more...

New proposal: - @zbraniecki If you're up for it, let's move the maintenance of `@fluent/web` into your GitHub fork. I'll archive the `projectfluent/fluent-web` repo and point to your fork in...

Thanks for opening this, @eemeli, and for a thorough analysis. Would https://github.com/projectfluent/fluent/issues/273 be a better place to discuss this? I'll reply here for now; if you'd like to copy your...

https://nodejs.org/api/esm.html#esm_dual_commonjs_es_module_packages has a good discussion of the available approaches. I think the most promising would be the `wrapper.mjs` approach.

Thanks for filing the issue! I've been thinking about something similar: `let {l10n, changeLanguages} = useLocalization();` but I think `setL10n` might be easier. @macabeus What do you think?

> Just adding the prop `setL10n` on `` and updating the value of `FluentContext` from `l10n` to an object `{ l10n, setL10n }` is the most simple implementation. Yeah, I...

Here's how I imagined `changeLocales` being used if exposed through the hook: ```tsx export function AppLocalizationProvider(props: AppLocalizationProviderProps) { let [currentLocales, setCurrentLocales] = useState([DEFAULT_LOCALE]); let [l10n, setL10n] = useState(null); useEffect(() =>...

If we expose `setL10n` instead I think it would become harder to manage `currentLocales`. In the example below, I can call `setL10n` but it won't have an effect on `currentLocales`...

The `fluent` runtime package takes shortcuts when parsing and resolving to avoid the perf cost of being 100% correct. There shouldn't be any tests which rely on this behavior; what...