I'm with gandalf that we should probably discuss expression changes
independently of entity markup changes.
I also think that I've got a patch to make us less brittle in the html
markup and error recovery case, I think we should roll that in and see
what it gives.
I also look back at my experience over using moz.l20n and/or tinker to
actually dive into the merits of the file format.
I think that we're in the scenario where ease of use is still dominated
by oversights and bugs in our toolchain. Which is OK, as we should make
sure the case where everything is fine works great.
If I had my way, we'd discuss changes to the file format based on
branched toolings, and then actually used stuff.
It's an interesting question on which level of tooling we want. Error
reporting is nice, and I think has to be there at the very least.
There's also a bunch of opportunities in terms of code assist, in
particular around indexes, expressions, plurals, etc. I wonder how many
of the pros and cons are related to this, and again, discussing them
without using them feels hard, at least to me.
Onto the actual proposals, I have a metric ton of stop-energy-NIH for
the lisp stuff. Like, I used emacs for ages, and never configured it to
my liking because of lisp. When it's Lisp, it's personal, y'know.
Structuring names, I'd side with gandalf on "keep it short, s...", the
namespace and name pairing looks strong enough. Unrelated on whether '-'
should be an ok part of an identifier, though.
On ':' in hash pairs or not, I don't have a strong preference, I guess.
I dropped the need for a : after the entity ID, and kept it for hashes,
just because I didn't bother the idea of changing hashes from JS.
Axel
On 7/15/15 7:34 PM, 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
