Hook in responsive localization early

[zbraniecki]

I understand why localization is always treated as an afterthought and every time a new approach to GUI comes up it comes with some version of:

Label::new(format!("current count: {}", self.count)).build(cx);

but I'm here to argue that this is both a bad paradigm and that the reason it doesn't get fixed is that once the GUI toolkit is mature enough to actually tackle the problem, there's too much sunk cost in this model to revisit it.

So I'd like to suggest you actually tackle it early :)

First, translation is not a string that one plasters onto a widget. It's a binding. Bind your widget to a localization unit.

In 20-years-ago command line textual apps, you could get away with such glorified printf, but that model very badly translates onto UI trees. UI element may be nested, have some internal structure, it's value may have markup and structure (think, <strong>, <sup>, <span> in HTML inside a string), it may have attributes, both textual (button's accesskey or tooltip) but also non-textual (color may be culturally dependent, icon associated with a button may be different for some locales, like rewind back/fwd in RTL cultures or some emojis in Japanese culture) and so on.

So instead of thinking of localization as a printf into a String, we should start talking about a compound object with multiple elements inside it - a Label or a Button or a Menuitem, and a compound localization unit that contains information needed so that those two combined can be laid out and painted on the screen.

Second, in reactive UI, retranslate every time the variable changes, or the locale changes (or the locale resources get updated!) during life cycle of the app.

Those two concepts work together really well - if you annotated by binding, you can just walk your UI Tree and retranslate at will using different localization resources whenever needed. You can cache the result, invalidate that cache and so on, without any overhead on the developer. You can localize asynchronously (think, you localize into fr-CA but midway through the localization stage you realize that some button cannot be localized and you want to fallback on fr resources, asynchronously load them and have the button be in fr as a fallback). You can do it because the localization pass is not related to how developer annotates the element with localization unit.

How would it look like?

In HTML we do:

l10n.res
key1 = You have { $emailCount } unread emails.
    .accesskey = K
    .tooltip = Number of unread emails

file.html
<label l10n-id="key1" l10n-args="{emailCount: 5}"/>

I think you can do better here. Maybe:

let mut label = Label::new();
label.l10n.args.set("emailCount", 5);
label.l10n.id = "key1";
label.build(cx);

There are deep consequences to that change in three directions:

1) how you think about UI, ergonomics, developer UX 2) how you think about DOM, layout, painting, invalidation, reactiveness etc. 3) how you think about locale management, live language switching and updating etc.

I can dive in all three of them, but I just wanted to start by suggesting shifting the approach to string injections early.

You can also treat an element as either controlled by l10n or manually:

let mut label = Label::new();
// Either
label.content = Content::Manual {
  value: "Static Value with { $emailCount }",
  attributes: {
    "accesskey": "C",
    "tooltip": "Foo"
  },
  args: args!(
    "emailCount": 5
  )
};
// Or
label.content = Content::L10n {
  id: "key1",
  args: l10n_args!(
    "emailCount": 5
  )
};

label.build(cx);

This is actually fairly common in my experience of working with Fluent. An example is when there's a menuitem that either takes a value from some database (say, credit card name) or displays a localized message "Unknown Type".

In such case we want to write:

cc-name-unknown = Unknown Credit Card
    .accesskey = U
    .tooltip  = The type of a credit card could not be recognized
    .icon = @icon-cc-unknown

menuitem.content = if let Some((name, accesskey, description)) = credit_card.get_label_info() {
     Content::Manual {
           value: name,
           attributes: {
               "accesskey": accesskey,
               "tooltip": description,
               "icon": format!("@icon-cc-{}", name),
           }
     }
} else {
    Content::L10n {
          id: "cc-name-unknown",
    }
}; 

This Rust code can be called every time menuitem list has to be rebuilt, but a function that updates translations is independent from it and can run on a different scheduler and react to different events, and be asynchronously loading resources blocking layout/paint, but not blocking this function.

[chris-morgan]

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!

[zbraniecki]

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.