Stanisław Małolepszy

That's a good question, thanks! I think the notion of the localizer's control is key. A simple key/value pair store takes away this control when we consider plurals, genders, or...

Good points, thanks @spookylukey. I can't think of good use-cases right now. I also agree with your last statement; it's safer to start with a more restrictive ruleset.

I have a vague memory of wanting to forbid exactly this kind of use-cases. IIRC, my argument was that this increases the complexity, makes the translations harder to reason about,...

``` -brand-name = Aurora .gender = feminine .anadrome = Arorua ``` Term's attributes were meant to capture metadata. The grammatical gender is a good example. However, the anadrome is not....

I've removed this issue from the 0.3 milestone. I'd like to release 0.3 shortly after 0.2 and I don't want to block it with this issue. It's something that we...

The last time I talked to @zbraniecki about this, we considered the following syntax for list-typed variant keys: ```properties key = { $items, $buckets -> [one][one] Found 1 item in...

The syntax idea which I mentioned in https://github.com/projectfluent/fluent/issues/4#issuecomment-356001351 has drawbacks related to the whitespace relaxation (#87): ```properties key = { $items, $buckets -> [one][one] Found 1 item in 1 bucket....

> If there are still reasons to consider the [one][one] syntax, we should make sure that it's possible to add it after 1.0 in a compatible manner. I'm going to...

Thanks for filing this issue! I removed the list data type because we didn't have clear use-cases for it, it was under-spec'ed and made the JS implementation more complex. The...

Thanks for the real-life examples! In your use-cases, does the number of elements in a list vary? In other words, is it "cows, pigs and sheep" for some users and...