On Monday, 20 July 2015 17:11:15 UTC+2, Staś Małolepszy wrote:
> Hey Richard, thanks for taking part in the discussion!
Thank you! I feel very welcome. :)
> The thing that bothers me in the current syntax is how cryptic it is. Take
> a look at this relatively simple example:
>
> <unreadEmails[@cldr.plural($emailCount)] {
> one: "You have one unread email",
> other: "You have {{ $emailCount }} unread emails"
> }>
I really don't think it's that bad. Maybe the @cldr part is hard to understand,
and the {} brackets might be redundant (since the entity name can't contain
whitespace and the index always ends with ], so it could still be parsed
without the {}.
And I definitely like the <> entity enclosure over more {} brackets.
> I've written about this before:
>
> http://informationisart.com/20/
> http://informationisart.com/19/
I think you're right about this, but I'm unsure how this would affect syntax. I
mean, you still need variable expansion/placeables and there are some uses
cases for entity references, so it would still need to be in the language,
don't you think?
> <availableSize "Il reste {{ $size }} {{ @get('_unit' + $unit) }}">
I'm not a big fan of this to be honest. I prefer dereferencing a hash/object
over this eval-type construct.
> The same i true for expressions and macros. What are the actual
> use-cases?
I think there are many use cases, with plurals being the most prominent one. I
think we should leave it up to the localization engineer to decide whether they
want to use macros/expression. I can imagine different time formats and things
like that as well (where you want it to say "just now", "an hour ago", "several
hours ago", "yesterday", "May 11th" et c depending on time passed).
We might want to focus on advanced plurals support (including
> animacy and personality) and some sort of string manipulation / lookup.
> Also an easy way to select a specific branch of code form things like
> @screen or @hour (hence my suggestion to add cond and condp, or a switch
> statement).
> I think this is a valid point and we've been in fact doing this for a while
> in Firefox OS already: all resource files are parsed and concatenated on
> buildtime into JSONs.
I'm not a big fan of the (somewhat verbose) JSON AST syntax. I like compact
file formats and have designed a few in my days. So if we wanted something more
compact, I could take a look.
> One of the criteria for "webbiness" is the ability to do a F5-style
> development, and any compile step prevents that.
I agree, and what a lot of libraries do nowadays is provide a runtime parser
for development purposes, and then a compiler for deployment/production. One
example among many being React.js.
Personally I rarely use the runtime parsers because I set up a build
environment with fast, automatic build-on-save, but it still makes sense and
could be one option. The runtime parsers are often viable options for
production as well, although not recommended.
> I like the idea of moving some (or all) globals into the $var space.
> However, to address your point about some globals not being available in
> certain environments, I'd like to point out that globals have always been
> intended as platform- and environment-specific.
I understand that was always the intention, and that's what made me wonder
whether they need to be their own thing at all (since they're not really global
in any other sense than the $vars are), instead of using the already existing
context variable space.
_______________________________________________
tools-l10n mailing list
[email protected]
https://lists.mozilla.org/listinfo/tools-l10n
