Comments (2)
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:
- We agree with you about the importance of localisation.
- Druid has had localisation designed into it, with half-baked implementation.
- 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.
- 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.
- 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.
Related Issues (6)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from crochet.