Lists in L20n

[Zibi Braniecki]

Hi all,

I'm working on Intl API v2 and I'm thinking on how to tie those features to L20n. My approach is to design API that can be used directly from JS (similarly to how Intl works right now), but in the back of my head I'm thinking on how we'll expose the same API from within of l20n so that localizers can use it as well.

One of first things I'd love to see is list formatting. CLDR provides the data for that and we can add list formatting which would benefit a lot of current Gaia apps that do it DYI way.

It would look sth like this:

var f = mozIntl.ListFormatter(navigator.languages, {
end: 'word'
});

f.format(['John', 'Mary', 'Nick']); // in en-US it would produce: "John, Mary and Nick"

--------

Now, when I think about getting it into L20n, one question that pops is how we handle lists. It feels to me that over last two years we removed the concept of lists and replaced them with Hashes, which works for values, but not necessarily for variables.

How can a developer pass a list as a variable, how can he access variable list elements (no integer, so no $var[0]) and do we want to just support sth like:

<myEntity "You added {{ @cldr.list($namesList) }}">

How does it look to you?
zb.

[Axel Hecht]

I guess there are two dimensions here?

How can localizers consume list formatting?

.... and ...

How can localizers implement list formatting?

Is that true?

It'd help me a bunch of we got the problem definition straight to begin
with.


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.

In either case, though, I would expect a "good default" handling for
lists, which might just be @cldr.list, independent of the syntax used.
Which, in a way brings us back to "how would a localizer implement
something else?".

Axel

[Zibi Braniecki]

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.