Why use providers instead of stores?

[samuelstroschein]

Hi Sebastian,

happy to see an i18n package leveraging Fluent. Is there deeper reasoning, other than replicating Reacts implementation, to use a provider pattern instead of using stores?

[sfriedel]

Hi Samuel,

the Provider definitely started out from trying to follow fluent-react's API. The provider at it's core is just a renderless component that initializes some stores used internally by the Localized and Overlay components. It also serves as a nice place to dispatch errors (currently only missing translations) which can be subscribed to via <FluentProvider on:error={doSomething} />.

There's no deeper reasoning than that :)

[sfriedel]

Samuel, I think your inlang project has a lot of potential. I only know of one other web translation service with fluent support which is pontoon, but it's rather heavyweight and depends on quite a lot of services. Having a lightweight alternative would be awesome.

I went ahead and created an example for SvelteKit using the store function approach. You can find the example here. It works quite well and feels "svelteish".

This is somewhat similar to a fluent integration that we built before svelte-fluent. I wouldn't argue against the store approach. The component-centric interface of svelte-fluent stems mostly from preferences here in the team and I think of them as (mostly) interchangable. It's only mostly interchangable because with components it's not possible to easily translate strings in the component script. There were some isolated cases where that would have been useful but could be solved in a different way by restructuring the code a bit.
I probably will have to expose a store interface at some point similar to what svelte-fluent already internally uses to perform the actual translations in the components. I'm still undecided though about whether the stores would become the primary translation interface in svelte-fluent and the components provide only utility or whether to keep the components as the primary interface to the library and have the store only as an escape hatch.

The possibility to render HTML elements with the @html prefix, in contrast to React, eliminates (?) the need for the overlay approach this package is modelled after except for decoupling styles from elements:

The lack of something like {@html} was not the reason them to exist in React (you could use dangerouslySetInnerHTML for the same effect) or fluent-dom (by setting innerHTML on the DOM nodes). The usecase for DOM Overlays is that you want to expose a limited and safe subset of HTML to translators. IMO the wiki article in the fluent repo is a good read.

Decoupling HTML attributes from the pattern seems desireable. Why should translators by bothered with setting the HTML attributes
and developers with modifying patterns?

I'd absolutely agree with that. It's similar to how fluent generally doesn't want developers to think of the exact wording of messages (because most developers aren't copywriters) translators shouldn't need to deal with HTML element attributes more than they need to. Also it protects from translators accidentially introducing unsafe or unwanted behavior. With {@html] translators could inject <script> tags or load resources via <img> and more.

Does an example/production repository that uses this package uses exist?
I would be interested in comparing the two approaches with "real life" scenarios.

Unfortunately the only production grade projects we use svelte-fluent in can't be shared publicly because they are contract work for clients.

How to i18n text which is not declared in markup with this libraries approach?

As written above, there is no straight forward solution with the component approach. In the case where I absolutely needed this (which were suprisingly rare) I ended up pushing the <Localized /> component higher up in the component hierarchy:

Outer.svelte:

<Localized id="some-text" let:text>
  <Inner x={text} />
</Localized>

Inner.svelte

<script>
  export let x
</script>

<div>{x}</div>

This is not ideal obviously which is why svelte-fluent will likely have to expose a store interface at some point.

[samuelstroschein]

I probably will have to expose a store interface at some point similar to what svelte-fluent already internally uses to perform the actual translations in the components.

Combining $t() and DOM overlays in one package correct?

I'm still undecided though about whether the stores would become the primary translation interface in svelte-fluent and the components provide only utility or whether to keep the components as the primary interface to the library and have the store only as an escape hatch.

Why would there have to be an either-or? Let the preference of the developer(s) decide?

The usecase for DOM Overlays is that you want to expose a limited and safe subset of HTML to translators. IMO the wiki article in the fluent repo is a good read.

Thanks for the link. One thing that is annoying about Fluent: The Documentation is scattered.

Adding safe HTML element lints to the @inlang/fluent-lint package might be a good idea. I opened a discussion https://github.com/inlang/inlang/discussions/112

Unfortunately the only production-grade projects we use svelte-fluent in can't be shared publicly because they are contract work for clients.

Can you share some insights in private? I am curious about your workflow. You can send me a mail samuel.stroschein <at> inlang.dev .

[sfriedel]

Combining $t() and DOM overlays in one package correct?

Yes, that's basically it.

Why would there have to be an either-or? Let the preference of the developer(s) decide?

It wouldn't really be an either-or. I was thinking more about how the documentation would be structured. Maybe having the same examples demonstrating both approaches would be the way to go except for overlays which would be hard to replicate with a store-only approach.

Can you share some insights in private? I am curious about your workflow. You can send me a mail samuel.stroschein inlang.dev .

I'm not sure there are many insights to share. The applications are primarily driven by a headless CMS and don't actually have a vast amount of static strings in the UI so the translation files are not that big. The workflow currently consists of manual management of the .ftl files, though tooling there would surely be appreciated. Pontoon seemed overkill for those projects.
Usage of the library for the most part consists of various combinations of what is presented in the Localized > Variables, Localized > AttributesWithArgs and Overlay > Variables storybook stories.

I've talked about this with my colleague and it may be possible to share some of the code in private, but we'd have to clear with our clients first. If you're still interested I'll ask him to reach out to you via email.

[samuelstroschein]

I've talked about this with my colleague and it may be possible to share some of the code in private, but we'd have to clear with our clients first. If you're still interested I'll ask him to reach out to you via email.

Please do so. The code itself is not a "hard requirement" to gain insights. For example:

driven by a headless CMS

Makes me wonder why the translations are not all handled by the CMS.

My mail is samuel.stroschein <at> inlang.dev

[sfriedel]

Please do so. The code itself is not a "hard requirement" to gain insights.

I'll let my colleague know.

Makes me wonder why the translations are not all handled by the CMS.

All content (produced by editors) related translations are handled via the headless CMS and delivered by API. The translations handled by svelte-fluent in those systems are translations for static UI elements like buttons, form field labels and similar things that are not editorial content.