Am 24/11/16 um 18:02 schrieb Glen De Cauwsemaecker:
Sections only affect which comments are in scope for which entity. If they
exist or not doesn't play a role for the developer or for how you reference the
entities.
Why are comments actually stored in the final Object Tree? When I was
working on L10n (C#/Unity), I simply omitted them after parsing. What
use case do they have for the user of the L20n Libraries?
There are two use-cases for l20n libraries. Applications localized with
l20n, and tooling to help localization infrastructure. Editors, linters,
dashboards and such.
For the applications, you only need the entries, whereas tools want the
full AST.
For JS, we have both an entries parser and an ast parser. For python, we
only have an AST parser so far.
We're building on top of ICU/CLDR for many of the formatting operations now,
instead of having localizers write macros to do that.
Could you collaborate on this? So that I can make sure I provide all
the formatters that you guys will support by default?
Also Builtins are both formatters and utility functions, correct? Or
do you call stuff like `DROP` and `TAKE` also formatters?
https://github.com/l20n/l20n.js/blob/master/docs/hacking.rst is probably
a useful pointer at how we're doing parameters. This isn't really solid
yet, as we're not using any of those features in practice.
Most uses of our builtins are very similar to filters in other
templating languages. So there's no clear constraint of input and
output, but in general, the output of one should make sense as the input
of another.
From an implementation-point-of-view, I'd suggest to annotate the
original data in each builtin, and only at the point where you convert a
placable to a string to be used as an individual text fragment, you take
all those annotations into account.
Related, if your platform supports BIDI separation markers, this is also
the point where adding those makes sense. So that you can do your best
for the BIDI algorithm if you mix up Arabic and English multi-word data
in a list passed in to a placable in l20n.
This still works, it's just not an explicit concept for now. We might add that
back if it turns out to be important in practice. Much of what we've done is
trying to make things simpler, and this was one of those things.
I like that, for now I'll also ignore it, keeping it simple sounds
good. L10n was really heavy on some parts.
We did remove PLURAL, as it's the same as NUMBER. That's required so that you
can match explicit numbers in the keys
Does that mean that when a NUMBER is used as a SELECTOR it is now not
anymore explicitly converted to `other`, `one`, `two`, etc? Or does it
just mean that PLURAL is merged into NUMBER?
Right. The selector code matches a number to a number, and if that
fails, it also matches the pluralform of the number to the literal. See
the selectors section in
https://github.com/l20n/l20n.js/blob/master/docs/syntax.rst.
Thanks for answering the questions so fast! :)
YW.
Axel
_______________________________________________
tools-l10n mailing list
[email protected]
https://lists.mozilla.org/listinfo/tools-l10n
