Hi Brandon, To clarify: I did not say that I think L20n (the language) is too complicated. On the contrary I think it's a very well designed language. I do however think that the _javascript API_ as it's evolving is getting too complicated. This is not a huge problem, because I could write my own API around the open parser.
I did however provide this feedback as input coming from a fresh pair of eyes, to start a discussion amongst the contributors about what would be the best way forward. I did not post it as an opportunity for you to shamelessly plug your proprietary, unfree (beer and freedom) SaaS, although I wish you the best of luck with it. Because I'm very new I don't know about the rules or etiquette of this list, so excuse me if I'm being overly harsh towards this kind of thing. I'd prefer if this discussion going forward would get back to being about the API, and would appreciate any thoughts on the feedback I provided in my previous e-mail. Cheers /R On Jan 24, 2015, at 2:01 AM, Brandon Paton <[email protected]> wrote: > Hi Richard, > > Agreed that L20n is a bit complicated for most use cases. > > About a year ago I created Localize.js for this reason > (https://localizejs.com). We use simple HTML tag markers to accomplish > interpolation (variables) and pluralization. I’d love to see L20N adopt this > approach as well — it’s worked well for our users so far: > https://localizejs.com/docs/usage/variables > > Brandon > > > >> On Jan 23, 2015, at 1:13 AM, Richard Olsson <[email protected]> wrote: >> >> I've been reading through this thread after a chat with stas, and although >> (or perhaps, because) I'm new to L20n and have very little insight (or >> interest, tbh) in the FxOS/Gaia project, I'd like to provide some feedback. >> >> I came to L20n via the tutorial on l20n.org and the documentation linked to >> from there (in the GitHub master branch). I've only just started out, but >> coming from gettext I'm already in love with the l20n language and am >> looking at implementing it in a major product of ours that's in the tech >> planning stage right now. >> >> 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. >> >> With this new API proposal, I reckon this simple (and for web apps fairly >> common?) use case will be bloated for the sake of a less common use case. I >> guess this approach is based on the needs of FxOS/Gaia? Maybe I'm just >> misunderstanding. >> >> I'm not sure what would be the best way to accommodate both use cases. Maybe >> two completely separate SDKs? I guess a strength with a project like this is >> that the core value of it is the ubiquitous l20n language, and it's entirely >> ok to have a ton of SDKs developed on top of it. >> _______________________________________________ >> tools-l10n mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/tools-l10n > _______________________________________________ tools-l10n mailing list [email protected] https://lists.mozilla.org/listinfo/tools-l10n
