In formatToParts, use type: "number" or type: unit? about proposal-intl-relative-time

[rxaviers]

Interesting question... By the way, you're talking about this (type: "number") right?

In date format, we can have several fields in the same output. As a developer, we should to be able to identify them, e.g., let's say we need to add a markup to the month part, which could be "dd/MM" in en-GB or "M/d" in en-US.

In relative time format, the output takes two forms: (a) it includes a literal part (the message) and a number that indicates a relative distance in a certain unit, (b) the message itself is the verbose relative distance (e.g., today). In the future, relative time format could potentially include a mix of things, e.g., "tomorrow afternoon" (not even considered here, but considered in ICU).

Always using "number" seems inappropriate given (a) and (b) above alone.

Do we want to differentiate the "Tomorrow" type from the "2" type in "in 2 days"? I mean, would we use day for both or two different types? Making a parallel with date, the type of "1" or "January" are both month), so perhaps not; but note that in date format the developer knows in advance what to expect (i.e., they know the output will always by a number or a text given the formatter style, e.g., month: 2-digit). In relative time, one type of message or the other depends on message-availability given value, e.g., "2 days ago" vs. "anteontem" both represent (-2, day), the first in en, the second in pt. Develop doesn't know what to expect in advance if we use day for both forms. I'm only thinking out loud here...

[littledan]

I was assuming we'd get "literal" for "tomorrow" or "anteotem", and just get "number"/"day" for the number "2". I'm not sure how much work it will be, as well, to separate out different parts of a worded message--if CLDR even has data for this.

[rxaviers]

cc @zbraniecki

[caridy]

+1 on using "literal" here.