Thanks for your feedback (to my feedback ;))
First of all I just want to be clear that the L20n language as it stands is
absolutely fine IMO. I'm just talking about the JS API (and about the design of
APIs for L20n in general).
Maybe it would make sense to think of the API as two-tier, one low level layer
and another higher-level. The lower level is essentially the parser/compiler,
with a synchronous get() method to retrieve an entity by ID from a loaded
resource (where resource is a first class object).
The higher level deals with the bits that need to be asynchronous, such as
locale negotiation and loading, "responsive l10n", HTML bindings and other
things that need to be implemented as callbacks, wrapping it all in a
environment/context. Still, underneath, they will just be invoking that same
get() method on the currently active resource.
The two tiers would probably live in the same repository, but would need to be
separated such that the low-level API could be used without the need for the
high level module to be included.
This would make it possible for someone who's just getting started, and people
not using frameworks, to use the high-level, asynchronous APIs. At the same
time, it would allow people who use frameworks that prevent them from modifying
the DOM directly for example (and who thereby can't hand that responsibility
over to L20n.js callbacks) to use the get() method directly within their
framework callbacks.
It would also allow for people to take the parser/compiler and wrap it in
something that makes sense for their framework of choice, and redistribute it
as react-l20n or whatever. The same approach could be taken to any language,
within the constraints of that language/environment.
Because all I really want to do is load a LOL file, and get entities from it. I
might even bundle the LOL in the HTML (based on a user default language setting
available to the server code) and load it from there. I still completely see
the use case for all of that other stuff, but I don't want it to get in the way
of the core functionality. :)
So basically the core, lower-level tier would just be this:
// Loading, which obviously needs to be async
var loadedResource =
L20n.loadResource('/locale/en/strings.lol').then(function() {
var entity = loadedResource.get('myStringId');
});
// Compiling from text (could be from HTML, XHR or whatever)
var lolText = document.getElementById('default-lol').innerText;
var stringResource = L20n.compile(lolText);
var entity = stringResource.get('myStringId');
Need negotiation and fallbacks, HTML bindings and the likes? Use the high-level
API or build it yourself. Need responsive l10n? Use the high-level API or just
get() on the window resize event. Etc.
How about it?
Cheers
/R
On Monday, 26 January 2015 18:42:14 UTC+1, Zibi Braniecki wrote:
> 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
