On Friday, January 23, 2015 at 5:03:09 AM UTC-8, Richard Olsson wrote: > My main takeaway from this thread however is that things are getting overly > complicated. I like the current synchronous API, which is completely enough > for our needs. More importantly, since we won't actually be doing much HTML > (using React.js and building a virtual DOM from JS) the HTML bindings are > uninteresting to us. > > The current API (GitHub master, which I guess is 1.0?) currently allows me to > very easily request a locale, wait for it to load, translate (and render) all > the strings. If the user switches languages, I will request a new locale and > repeat. Each component can render the strings sychronously once they have > been loaded. > > Since we are in complete control of our application, we don't need the amount > of runtime fallback logic that this API is being designed to accommodate. > Quite the opposite really, if a string is missing I want to fail in some way > (exception, or return entity name) so that we can catch that in our testing.
This is an awesome piece of feedback. We need this. The problem we face is that we are designing L20n to be platform and system agnostic, but the first platform we're shipping on is FirefoxOS which means vanilla webapps. It's good because it involves modern platform, and front-end work which L20n helps most with, but it also means that we keep things like python/django/node/angular/react etc. implementations only in the back of our heads and we kind of run our mental model experiments each time we update the API design with "Will that work for django? Hmm, it should" - done. Lack of experience with JS frameworks makes it harder for us to understand the interactions between l20n and those frameworks especially in the areas where they may overlapp (our responsive l10n vs. two-way data bindings or live retranslation case). I believe that this is artificial and l20n should be able to plug into those frameworks easily. L20n as a library should be standalone, pluggable and bindings agnostic. Then, bindings should be enabled when l20n is localizing vanilla webapp and bindings should be the part that we're pushing on WebAPI track. This separation of concerns would help us tremendously and make us a good citizen in the frameworks world. zb. _______________________________________________ tools-l10n mailing list [email protected] https://lists.mozilla.org/listinfo/tools-l10n
