On Monday, August 31, 2015 at 2:35:39 PM UTC-7, Axel Hecht wrote:
> I guess there are two dimensions here?
>
> How can localizers consume list formatting?
>
> .... and ...
>
> How can localizers implement list formatting?
>
> Is that true?
Yes!
I am currently more fixated on the consumption than implementation, but down
the road, I'd like us to understand that List is a potentially valuable type of
data, something we removed back in Parkcity :)
> More systemically, I'm still somewhat inclined to differentiate between
> macros and filters. Maybe I'm django-infected here a bit more than useful.
>
> I think there's a difference between {{ @cldr.list($nameList) }} and {{
> $nameList | @cldr.list }}. To some extent it's just markup. But there's
> also a level of "decision-making" between one and the other.
>
> Not sure if it's worth it, though.
I'd be curious to hear more about that differentiation. I can see how
stylistically filters look good, but I feel like the struggle is always in
chaining them.
So, while {{ $nameList | @cldr.list }} looks good, if I want to pass the result
to a macro, doing {{ myFormat($nameList | @cldr.list) }} feels a bit more
awkward.
Also, the question is how would it handle that in indexes and macros.
Would you be willing to start a new thread to discuss that?
> In either case, though, I would expect a "good default" handling for
> lists, which might just be @cldr.list, independent of the syntax used.
Yeah. I agree.
> Which, in a way brings us back to "how would a localizer implement
> something else?".
And that's a great question. My original thinking for this thread was a bit
more shallow, but I like this tangible example.
I was just worried that in our process of thinking back in the day when we were
shaping L20n format, we decided that we don't need lists, so we don't need list
expressions and accessors either. Everything, we argued, can and should be a
Hash.
So now I'm back to conclusion that we will actually have lists floating around.
Initially, I see them coming from variables, but eventually, I can imagine a
scenario in which we'd like a localizer to provide a list of localized values
of arbitrary length back to the developer.
But no matter if we will go there or not, we will have to handle lists. We can
do this in a opaque way (localizer cannot interact with the list, he can only
pass it to a global macro) or we can start thinking on how we want to enable
localizers to interact with list variables.
zb.
_______________________________________________
tools-l10n mailing list
[email protected]
https://lists.mozilla.org/listinfo/tools-l10n
