Hook in responsive localization early about crochet HOT 2 OPEN

Thanks for your thoughts; it’s nice interacting with others that care about these topics as well!

Localisation is something that we care about, and which will definitely be solved well inside Druid. In fact, Druid already uses Fluent, having some half-baked localisation support where it stores the Fluent resources for the current locale in Env, so that any lens or widget can access it, and has a type LocalizedString that makes strings translate properly with lensing, so that you can have Label::new(LocalizedString::new("key1").with_arg("emailCount", Self::email_count)), and it’ll update when the locale or the data change. (—I’m actually not certain if locale changing is hooked up at this time, but it’s designed soundly so that it can work. As I said, it’s half-baked; but the foundations that have been designed are sound.)

We’re also well aware of all of the other nuances of localisation, that it’s not just text labels, but other properties as well.

So that’s Druid. This is Crochet, an experiment in replacing Druid’s lensing approach.

One of the motivating reasons for Crochet is that lensing means that the widget must manage reactivity itself—so Label uses a lens for its text, but if you want colour to be reactive, the Label widget needs to have deliberately used a lens there, and if it hasn’t, you’re out of luck. But under Crochet, all attributes become reactive at very little developer or runtime cost. This will make Crochet even better for localisation: now you can do much more involved UI changes by locale without the widgets having had to be carefully designed for it.

Back to what Crochet is at present. It’s an experiment in one particular area: replacing lensing. Consequently, we’ve stayed away from adding any localisation yet, because we know it’ll work within the model (more easily, in fact), and implementing it at this time would be just a distraction from testing the viability of the overarching concept.

Notwithstanding that, your post has made me think a bit more about how Crochet’s concept of attributes (not yet implemented, but discussed on our Zulip chat—join us if you like!) might fit in with Fluent attributes. There’s scope for some some really nice ergonomic synergies _{^{[there, I said it]}} there. I think it should end up at least as nice as the concepts you’ve listed there, which it definitely couldn’t have done in the lens-based approach.

Summary:

1. We agree with you about the importance of localisation.
2. Druid has had localisation designed into it, with half-baked implementation.
3. We’re confident that localisation will fit into Crochet very nicely, better than in Druid’s lens design, and our confidence is backed up by plenty of practical experience in software localisation.
4. But I don’t think we feel the time is right to implement it just yet—we’re prototyping other things and proving other concepts for now.
5. Come join us on Zulip if you’re interested!

from crochet.

Thanks for your response!

The other side of the equation I'd like to direction your attention to is nested UI fragments. I'm going to use HTML here, but I think it translates to other UI paradigms quite well:

<h1>
  Welcome to <strong>New</strong> <sup>Mr.</sup> Proper.
  <a href="https://www.myproduct.com" title="Links to our product page">Click here</a> to read more.
</h1>

In Fluent, we implemented a very simple DOM Overlays which allow us to do:

HTML:

<h1 l10n-id="intro">
  <a href="https://www.myproduct.com"></a>
</h1>

L10n:

intro =
    Welcome to <strong>New</strong> <sup>Mr.</sup> Proper.
    <a title="Links to our product page">Click here</a> to read more.

And we'll overlay those two preserving source information so that we can retranslate to another language from the source rather than from the output of source+en-US.

Couple things to notice is that we allow for a subset of HTML elements to be introduced by the localizer - those elements are called text level semantics and they're safe tags like strong, sup, em etc.

The other elements must appear in the source and then we match them - href comes from source, so that the localizer doesn't have to bother (and developer doesn't have to update all translations when the href changes), but the title comes from the localizer.

That's just a beginning, but it's something that binding model gives you, and
Label::new(LocalizedString::new("key1").with_arg("emailCount", Self::email_count)) will not, together with the attributes.

from crochet.