Cool stuff Stas!
On Wednesday, July 15, 2015 at 10:34:39 AM UTC-7, 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.
My only concern with regards to using '{', '}' for expanders is that it's much
more common to use it in a string than '{{', '}}'. Which means that now you
have to escape a normal character because of its special function in L20n.
Not sure how to evaluate how much of a problem it is. I hate escaping
characters, but I believe that '{' character is indeed rarely used in regular
text.
I searched through our translations and what comes to mind are:
- CSS in L10n will have to be unescaped
- JS Template strings will have to be unescaped because they use `Hello,
${user.name}` notation
- Some of our build tools use ${AB-CD}
- In one place Gaia Email app uses {name}
https://github.com/mozilla-b2g/gaia/blob/1ee07b1bf55894dc7bad8e4a2e31d77c59cf4106/apps/email/locales/email.en-US.properties#L664
Overall, it doesn't look bad. I'm a bit worried about overlapping syntax with
ES6 Templates.
> - Improve error recovery and make it easier to use HTML in translations.
Here I feel like we're fixating on HTML. If L20n syntax is supposed to be
language agnostic and useful for different environments, then fixating on
making it convinient for HTML may be risky. How will it work for Rust? Python?
Jinja? CSS?
I'm also of course curious how will Hashes look like.
> - 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.
I don't like this change.
First, I believe that we should avoid naming pollution which I believe we
should achieve by using namespaces.
@intl.*
@cldr.*
@gaia.*
On top of that, I'm don't think that lisp style expressions are helping here.
I've been using lisp style expressions in multiple environments and I always
felt like they're alien compared to classic C syntax.
First, I believe it's harder to notice an error and harder to create a useful
recovery message. Consider:
`callExpr param` - all possible combinations of mistakes - `callExpr,param`,
'callExpr.param`, etc.
`callExpr(param)` - we can easily report to the user sth like `callExpr[param)`
and suggest a solution
Secondly, by far the language that localizers will know the most is JavaScript
or some expression subset of CSS3/CSS4 (which follows JS syntax). Lowering
entry barrier by presenting them familiar syntax to code the may know even if
they only know a little is a huge benefit.
While it may be a matter of habit and preference, I believe that imposing
something likely less familiar to localizers for disputable benefit is a wrong
design decision.
As a mental experiment, design polish cldr.plural macro with your syntax and
show it to a sample of localizers compared to current L20n expression syntax
one.
What do you think they'll likely find more familiar? Where do you think they'll
likely make more mistakes in?
> - Allow to use dashes in entity names.
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}`
Also, teaching people that a variable may be `email` and a variable may be
`count` and that we do have substration operator `-` but that `email-count` is
not an expression but an entity ID is imho very confusing.
> - Make it possible to reference entities by dynamic names unknown at parse
> time.
I like this feature, but not sure if there's a real use case for that and if
so, I'd expect it to be rare enough that we shouldn't design syntax around it
imho. (in other words, {{ :[variable] }} would do)
> - 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 like it, although I'd like to combine it with globals, which I think are
valuable to preserve.
I'm also not sure if ":" is better than "$", especially if we want to use ':'
to denote value variants. Because in that narrative that makes entities
variants of context?
My suggestion:
- $entity1:masculine
- $entity1.ariaLabel
- @cldr.plural
- user.name
All in all, I'm all in favor of revisiting the syntax and I think it's a good
moment for that. I'd love us to get to Gaia devs and localizers and ask them
for feedback. I'd love them to tinker with our current syntax and tell us where
they have problems and come up with ideas. I think it's a perfect moment for
last revision of the syntax and probably the last one before we have to make a
call and stabilize it if we want to start using it in time for Firefox OS 2.5.
zb.
_______________________________________________
tools-l10n mailing list
[email protected]
https://lists.mozilla.org/listinfo/tools-l10n
