Naming for type: numeric/text about proposal-intl-relative-time

[rxaviers]

Hello everyone, I couldn't join the last call, but here are my thoughts:

Given the amount of confusion above, it turns out no suggestion so far would be crystal clear for the end user. Therefore, I encourage we rethink it, see below.

Both outputs are identical except for a few cases, i.e., what we're calling numeric vs. text actually have identical outputs (e.g., 3 days ago, 4 days ago) except for -2, -1, 0, 1, 2 cases (e.g., yesterday instead of 1 day ago). Therefore, there aren't two different output types, but an output modifier for a few cases. Therefore, I would consider something like casualDisplayNames: true (or a better name) instead of using two different output types.

What do you think?

[zbraniecki]

We'd like to suggest a consensus proposal for this:

numeric: [always | best-fit]

Are there any objections to this proposal?

[sffc]

I'm satisfied with Zibi's consensus proposal, but thought I'd throw out one more…

numeric: [always | auto]

with the default being "auto". The word "auto" is popular in CSS.

[littledan]

Auto seems good to me if others support it. Best fit is used for implementation specific locale negotiation today, whereas this is well-specified, so auto seems better.

[sffc]

In principle, I like the idea of casual: true, but I don't really like booleans because they restrict possible additional settings in the future. For example, maybe a future setting would allow for enabling spell-out separately for days ("yesterday" vs "1 day ago") and weeks/months ("last week" vs "1 week ago").

I don't think CLDR has any particular name. The CLDR Translation Guidelines call them "Relative Date Names". They are also described as just "words":

Some languages have a special word for "The day before yesterday", which may also be displayed for translation.

Maybe make "words" the key as follows?

words: "never"  // "1 day ago", "3 days ago", "1 month ago"
words: "always" or "when-able"  // "yesterday", "3 days ago", "last month"
words: "days-only"  // "yesterday", "3 days ago", "1 month ago"
words: "months-only"  // "1 day ago", "3 days ago", "last month"

[icambron]

This is, uh, not what you should do, but a very pedantic version of this is to call the "tomorrow"-like ones deictic and the always-numeric ones durational

[littledan]

Interesting idea. To clarify, I was actually looking for a new name for type, but we could also rename the values as well if numeric/text feels unclear to people.

[icambron]

Hmm, OK. For what it's worth, I read the @rxaviers comment you referenced to be about the numeric/text values, not the key.

[littledan]

Oh sorry, skimmed way too quickly. Others have had concerns about the type too.

[caridy]

I have concerns about both:

• type as the key doesn't ofter signal that it will affect the output, it is often used to describe the input's type, or some details of the value that is provided rather that the type of output.
• type: 'numeric' and type: 'text' are also confusing because all formatters are outputting text, that's what they do. Saying that it outputs numeric seems weird, while saying that it outputs text seems redundant. I will like to bikeshed on a better name for the key, and find some meaningful possible values for it as well.

[icambron]

I mean, why not just output for the key?

[littledan]

Don't all the options relate to the output?

[zbraniecki]

I do not share @caridy concerns and I find the type key to work as "the type of relative time formatting you want", and for values text indicates to me an attempt to present the relative time in a textual manner, while numeric represents numeric.

I'm not willing to block on this so if there's a better option, I'm ok with us switching.

[caridy]

@zbraniecki last week you mentioned something about the type configuration changing the type of computation that we do in order to provide the right output. More similar to localeMatcher in DateTimeFormat, if that's the case, why not using a name and possible values that reflects that?

[littledan]

We discussed this at the January 2018 ECMA 402 phone call, and the group found the current name to be confusing. We agreed to continue bikeshedding on the name on this thread. What names do you think would be good here?

cc @nciric @sffc @caridy @zbraniecki @jungshik @jackhorton @dilijev @eemeli @srl295

[sffc]

ICU uses the word "width" to describe this: something along the lines of width: "narrow" and width: "wide".

If the words "style" and "type" are overloaded, maybe something like "form" or "mode" or "method" with values "numeric" and "spellout"? form: "numeric" or mode: "spellout"

[dilijev]

I like form as the key name. With that as a key, I think "numeric" would probably be fine as a value, but in that case I wouldn't know what to call the non-numeric version.

If we're looking for exactly two values, perhaps form: "casual" and form: "precise" might do the trick (where casual includes terms like "yesterday" and precise for exact numeric renderings).

mode doesn't seem to be a good key name for this idea -- I'm not sure I would think of anything involving linguistic production/rendering as a "mode" (unless we're speaking in the sense of "conversion mode" from time interval to text, which might be how a programmer is more apt to think of this, but I still feel like that's a stretch with some mental gymnastics involved because we know exactly how to calculate one day and we're doing that calculation regardless).

spellout seems to be an alphabetic-script-centric idea -- consider Chinese 前天 (lit: "before-day", a word meaning "the day before yesterday") and 两天前 ~ 2天前 (lit: "two days before") -- these are different forms but "spellout" doesn't really seem to evoke the difference [1]. (Also, I'm not sure that specifying an exact time unit requires using numerals necessarily in certain languages.) If anything "spellout" would seem to evoke the idea that instead of "1 day ago" I would get "one day ago", but suggests nothing at all about whether or how I could produce "yesterday" from the API. (Chinese: 1天前 / 一天前 / 昨天 respectively.)

Furthermore, spellout might mean something different than you'd expect in some languages -- e.g. in Japanese, I might expect spellout to mean to use kana (phonetic spelling) instead of kanji (symbolic), but nothing about whether a numeral or equivalent character is involved.

I think numeric is fine but I think that terms like narrow and wide are perhaps not really helpful in understanding what you would get from the API... I imagine the relative lengths of "casual" terms versus explicit numeric terms wouldn't be the same in every language. Even in English, "1 day from now" is longer than "tomorrow"; "1 day ago" is the same length as "yesterday" if you count the spaces.

Initially I liked @icambron's suggestion of deictic and durational. However, after I researched the term deictic further, it seems all renderings of relative time would be considered deictic and we're not talking about duration at all, but rather relative times rendered in different forms.

[1] Whether to use numerals (and which kind, Chinese or European[2]) is probably up to the database, e.g. CLDR. "两" versus "2" is pretty much the same as the difference between writing "two" versus "2" in English, although the character replacing "2" here has more of a nuance of "a couple of" and is pronounced differently than the Chinese ordinal numeral 2 ( 二 ) -- which would be the resulting character from a naive conversion from European to Chinese numerals (as it would somewhat assume standalone numerals) but is grammatically incorrect here -- so this decision may be different from language to language. Does this API have any concept of forcing numerals versus words?

[2] For simplicity, I'm calling Arabic numerals such as are used in the Latin script (and others) as European numerals, to avoid confusion with true Arabic numerals.

[dilijev]

Even though I suggested it, I somewhat worry there might be inter-locale issues with the term casual for this concept -- unless that's really the distinction the API is making across all languages (I'm not well informed enough about all the languages and their renderings in CLDR to know this). What terminology does CLDR use? -- I think so far we've only mentioned ICU terminology in terms of precedent.

FWIW I tried a cursory search through linguistic terminology and couldn't come up with a sufficient term to capture this difference. It's possible there isn't one...

[dilijev]

@sffc Agree with the concern about booleans. I like the above idea and terminology in general. words is definitely moving in the right direction IMO.

I think "always" might be misleading, and "when-able" is too wishy-washy. (For that matter words: "never" might be misleading too, because everything but numeric terms are still words).

So for now we'd be starting with the first two semantic values, actual string values TBD. My suggestion would be "best-fit" (has a precedent as a term in Intl already and doesn't say anything about frequency or which if any values would be displayed differently -- allows language differences not to defy programmer expectations):

words: "never"  // "1 day ago", "3 days ago", "1 month ago"
words: "best-fit"  // "yesterday", "3 days ago", "last month"

It sort of works if these are the only two keys, but if we add "days-only" | "months-only" semantics, it doesn't seem that great

Re: *-only as a future extension: I imagine this sort of as a bit vector with all bits mutually independent... What if you want days and weeks, but no months. How would that sort of "select each time interval independently" semantics scale with string values for the words key? (Or can you only request none, one, or all?)

Edit: "best-fit" actually seems okay even in the context of *-only. Still have concerns about bit-vector-ish behavior (which of course is not in scope for this proposal anyway).

[dilijev]

What if we explored numeric as a key rather than a value:

numeric: "always"  // "1 day ago", "3 days ago", "1 month ago"
numeric: "best-fit" or "allow-words" // "yesterday", "3 days ago", "last month"

[dilijev]

For that matter words: "never" might be misleading too, because everything but numeric terms are still words

Maybe words: "numeric" instead? That way we can come back to this idea of numeric versus relational but the key isn't type which IIRC was the main objection to numeric originally.

words: "numeric"  // "1 day ago", "3 days ago", "1 month ago"
words: "relational" or "best-fit" // "yesterday", "3 days ago", "last month"

Using "relational" instead of "relative" avoids overlap with the name of the feature, but probably shares the same tautology objection ("any relative time is already relative/relational so what does this mean"), however I think "relational" captures the type of terminology better than "relative" does.

[dilijev]

Maybe use the key display instead of words for the above, to avoid the appearance that numerals are not allowed -- but I imagine this objection would still apply:

Don't all the options relate to the output?

[eemeli]

I like "casual" as a differentiating term between "yesterday" and "1 day ago"; none of the others that have been mentioned communicates (at least to me) clearly the difference between those two expressions. Now, whether that term should be used as a mode or as a modifier is a separate question, which is best considered in the context of the rest of the API.