On Wednesday, July 15, 2015 at 5:49:12 PM UTC-7, Staś Małolepszy wrote:
> That's the point, actually :) By forcing { and } to be always escaped we
> can make sure that literal { } are either meaningful or are errors. We
> don't have this luxury with <> now.
Yeah, which in turn may lead to a confusing state between unclosed expander vs.
unclosed entity. But I'm ok with experimenting with that!
> Yeah, good point. I'm not too worried about Bash variables or that one
> vvariable in Gaia's Email. I'm not sure about Jinja or es6 templates.
> Would they be orthogonal to L20n or complementary? Does it even make sense
> to have (escaped) es6 templates in translations?
I don't think it does. But the developer dealing with es6 templates right next
to L20n overlays may be confused. I'm also wondering what will happen with
angular/react templates in the context of l20n.
> This is again a good point and I'm aware that there is world out there
> beyond HTML :) That said, I think it's well aligned with Mozilla's mission
> to push for HTML as the de facto standard of building localizable UI.
Good point. I think that convinces me.
> It's in the gist:
>
> ; index is defined in []
> ; hashes are defined as series of hash pairs {}
> ; the default hash pair is marked with {* }
> ; hash keys are symbols or strings
>
> { notifications [(plural n)]
> {* one "{ n } notification"}
> {many "{ n } notifications"}
> {"two words" "{ n } notifications"}}
Ok, then we have the same open-close character for entities, hash values and
expanders. That's worrying.
> I went for the hash-pair approach instead of key-value-map one to emphasize
> the fact that variants are independent units of translation. They're
> different facets of the entity and I wanted to make that clearer with a
> syntax that's similar to the syntax of the whole entity.
I don't think I like it. Once again, the most likely comparison people will
have is JS Hash Values and I think it's a good one. I prefer
{notifications[plural(n)] {
*one: "{ n } notifications",
many: "{ n } notifications",
other: "{ n } notifications"
}}
> I like namespacing, but 1) I'm afraid of creating spurious hierarchies with
> one elemnent and 2) it can be achieved by convention, e.g. intl-datetime.
I believe that that's exactly the argument that PHP authors used and that led
them to an API mess.
I'm much happier with one-element namespace, then flat list of namespace-like
conventions with strpos, strslice, intl-numberformat and cldrPlural.
> Consider this: you can probably write an entire S-expression parser in 100
> lines of code. They're super-easy to implement too, which will make the
> resolver simpler.
I would prefer us not to design a challenging piece of L20n around how easy it
is to implement, but how easy it is to learn and use.
> We want expressions to support complex logic and in L20n 1.0 we paid for
> them while arguably they aren't used much.
Which is ok. We now introduce them in 3.x slowly and see what we use. I believe
that the original scope of the expression syntax was designed to express plural
macros and I think it's a good limit.
> Only a handful of localizer-engineers will write new expression code. So I
> think there's a benefit of providing complex expressions without bundling a
> complex implementation.
I don't believe we know that. I don't think we got to the point where we know
how commonly localizers will use expressions and my gut feeling is that they
will use it more often then we assume.
And as I said before, I would prefer us not to focus on implementation cost
when we're working on design.
> I don't think C-like expressions give us that edge at all.
And I don't think that that's the edge we should be focusing on.
> A form always looks the same (operand ...args). There are fewer kinds of
> parsing errors. OTOH, we're able to catch more errors in the runtime: e.g.
> (entity 1) should return "Invalid argument type passed to &entity".
how is it better than entity[1] or entity(1) ?
> Our C-style expressions are very limited: they're always a single
> expression which makes the ternary if the only way to branch, and that's
> tedious.
I don't understand your point here.
> I think S-expressions give use a bit more flexibility by allowing
> different interpretations of the arguments passed into form, like in (cond
> ...) which takes an even number of args and pairs them together to create a
> multi-branch if-else.
I don't think that we need more flexibility and definitely I don't think that
making looser syntax that leave more to the interpretation is going to get us
less errors.
> I did that! I'm sure I'm not being objective here, but the new syntax
> looks leaner to me.
I believe that you are not objective here. It's a matter of taste but you're
introducing a lot of esoteric tokens like &true, mod, or, and (which look like
variable), while at the same time trying to minimize the number of special
characters.
I'm going to even skip the fact that the way we teach people math is by
teaching them "a + b" not "+ a b", so the former is by design more
recognizable. I believe that your approach is going to significantly increase
the entry barrier and basically make the code harder to maintain when new
people will try to work with pre-existing localizations.
I also feel like we're going to be less "webby" because all web technologies
use C-like notation for arthmetic operations and JS-Object style notation for
Hashes (see CSS, JS, JSON).
> > I would not claim it to be a major win especially since it would require
> > localizers to switch between JS syntax and lips syntax for things like `{-
> > email-count emails-total}`
> >
>
> Why would they switch to JS?
Sorry, I means developers here. I just don't think that lack of '-' in ID is a
problem. CSS doesn't use them, JS doesn't use them. Seems like web technologies
do just fine without it.
> The subtraction operator can only be found as the callee in form, so it's
> really more like an operand or simply a function call: (- a b).
Well substraction operator may also be found in the middle of the ID in your
example.
> I've noticed this could be helpful when you'd want to dynamically choose an
> entity in some other translation: maybe byte units, maybe city names,
> maybe something else. People seem to want a data-store-like structure that
> they can retrieve things from. Without dynamic references to entities, they
> resort to using hash value, which is bad because hashes are for variants of
> the same thing, or to attributes, which also wrong because why would these
> translations pretend to be metadata of some made-up entity? I think all of
> those should be separate private entities and it should be easy to access
> them without knowing the identifier a priori.
I'm really worries about a scenario where people try to pass values from the
user to l20n and resolve entity with that ID. I like the idea that the
developer defines and calls ID names.
And, as I said, we can do this perfectly fine without lisp expressions.
> I'm keeping globals in form of library-provided symbols! &defmacro or &and
> are what we call globals in 1.0 and 2.0. The only convenience is that you
> don't have to type the & if you're calling them in an S-expr: (and &true
> &true).
That's even more complicated and confused I believe.
Also, I much prefer to have `and` as part of the expression syntax than a
global call.
> How about the... hash? :)
>
> :entity#one#feminine
I think I prefer $entity:one:feminine over that.
I also prefer :entity:one:feminine. But I believe that the opening ':' is
confusing.
> :entity.aria-label
> &cldr-plural (when used not as callee)
> (cldr-plural 3)
Definitely prefer @cldr.plural(3).
I can imagine going back to your idea of special-casing name `global` or `env`.
and then env.cldr.plural instead of '@'.
> Also note that all of these shorthands will require a little bit of special
> parsing because they're not S-expressions. We could work around this
> problem (at least for now) by only allowing access via dedicated symbols:
I think that we should discuss pieces of your proposal separately instead of
building one of top of another to avoid the illusion that it's "all-or-nothing"
scenario. I like many of your changes, I don't think that your expression
syntax proposal is a good change. I'd prefer to discuss those things without
false implications.
> Last but not least, I'd like to keep @ out of the syntax and use it for
> docstrings like @param.
I'm not sure how special characters in a comment collide with expression
syntax. In docstrings, the '@id' are only meaningful if they are at the
beginning of the line preceeded by whitespaces. We won't have any case like
that with expressions.
zb.
_______________________________________________
tools-l10n mailing list
[email protected]
https://lists.mozilla.org/listinfo/tools-l10n
