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
