Wow, I'm loving the discussion. I made a lukewarm attempt at joining the work on L20n maybe six months or a year back, but never quite got into it because the project didn't feel as alive back then. I'm very happy to see such fundamental topics as the syntax being discussed, and am inspired to give it another try. So please bear with me since I'm still pretty new to the project.
Personally what attracted me to L20n was the syntax, and not the integration with the web front-end stack. I think the original syntax works great, and although there are some minor tweaks in Stas's proposal that I wouldn't mind, I think Zibi has the more valid points on most issues begin discussed in this thread. My main concern when I came across L20n was l20n.js, and how the L20n language to me felt very tightly coupled to javascript and HTML. It seems to me as if many of the concerns being voiced in this thread are related to that same fact, and I don't see why it need to be that way. If the desired syntax is too (technically) complex, making the parser heavier than is considered ideal for a browser app, why not pre-compile to a format that can be more easily parsed instead of changing the source syntax? The mo/po approach is actually one of the few things that I don't personally hate about gettext. :) This might seem a little bit off-topic, but it's part of a general way of thinking of L20n and the JS API as separate, which could actually affect some of the syntax questions. One example is the global @screen context, relevant in this discussion because of the @ prefix. I'm gonna go out on a limb here and say that I don't think globals should be in the language at all. While responsive localization is a great thing, the screen size should be a context provided by the browser JS API, and hence just be a normal $var. Most web localizers wouldn't know the difference, but it keeps the language cleaner and avoids taking on responsibilities which can prove to be very difficult, like how to deal with timezones for @hour (locale != timezone), or @screen when localizing on the back-end. I have lots more to say about the API and separating L20n from the SDKs, but nothing that is strictly relevant to the syntax of L20n, so I'll leave it for now. :) Cheers /R On Wednesday, 15 July 2015 19:34:39 UTC+2, Staś Małolepszy wrote: > I made a thought exercise of imaging what it would be like to design the > L20n syntax from scratch, today. > > I was guided by the following goals: > > - Make the most commonly used syntax easy on the eyes and easy to > understand. > - Improve error recovery and make it easier to use HTML in translations. > - Make it easy to parse complex expressions. They are important for the > advanced features of L20n, but cost a lot in terms of parsing and resolving. > - Allow to use dashes in entity names. > - Make it possible to reference entities by dynamic names unknown at parse > time. > - Make it clearer that translation variants are different permutations of > the same translation data and as such, they are different than attributes > and are not part of the social contract. > > I created a sample file with a new proposed syntax. Nothing is set in > stone yet and I'm looking forward to hearing your thoughts about the goals > and the proposal. > > https://gist.github.com/stasm/c99010a8ab6d467562ba > > Thanks, > -stas _______________________________________________ tools-l10n mailing list [email protected] https://lists.mozilla.org/listinfo/tools-l10n
