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 <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 <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
