Review handling of "narrow" style

[Ms2ger]

Looking at CLDR, English only defines short variants of the data relevant to this spec, and doesn't define narrow variants. However, SM and V8 appear to use the short variants when passing the "narrow" option:

const rtf = new Intl.RelativeTimeFormat("en-US", {
  "style": "narrow",
});
rtf.format(1, "second"); // "in 1 sec."

AFAICT, the spec doesn't seem to back that up.

[littledan]

Pedantically, I don't see how the spec prohibits this behavior, but I think we should double-check whether we expect to ever have narrow data. I only see narrow strings for relative days of the week, which we don't support. Does CLDR have any nontrivial narrow data for RelativeTimeFormat in the modes we support? If not, we may want to remove the option.

[zbraniecki]

Polish handles narrow for second - http://www.unicode.org/cldr/charts/34/summary/pl.html#1427 (among others) - is that good enough?

[littledan]

Maybe a more relevant reference would be http://www.unicode.org/cldr/charts/34/summary/pl.html#1664 , but yes, that seems good enough. Now, should we indicate in resolvedOptions that we've fallen back from narrow to short in English, or do it implicitly? Currently, the spec would only permit implicit fallback.

[zbraniecki]

I think we should adjust the resolvedOptions style to match what we resolved to.

[zbraniecki]

We discussed it during the ecma402 monthly call and came to the conclusion that in this case CLDR does present the short format as the narrow one.

So what ECMA402 should do is take the narrow form, poll CLDR which will return alias to short and report is as a narrow in resolvedOptions since this string is the narrow form for the given language.

Closing the issue.

[srl295]

cldr root.xml actually has

                        <field type="second-narrow">
                                <alias source="locale" path="../field[@type='second-short']"/>
                        </field>