sffc
commented
1 year ago - @markusicu - We're talking about a number formatter that supports a single unit, right?
- @younies - Or a single currency.
- @markusicu - But it's not a "single number formatter"; it's a number formatter that supports a single unit or currency. "Single number formatter" is a misnomer.
- @younies - We should decide on whether we have a single crate or multi crates before choosing the names.
- @markusicu - If we go with the first option,
SingleUnitNumberFormattermight work. - @younies - I prefer two crates. (1) Users often want only one or the other between currencies and units. It can allow easier slicing of the data. (2) In the future we might have more complex combinations like "1 USD per gallon". We can combine them in the complex unit formatter.
- @sffc - I don't think we should start having a dozen crates for number formatting. A dozen types or modules, sure, but crate boundaries are heavier. We can get the code and data slicing the same with a single crate. An advantage of a single crate is that we can share helper/utility functions for things like pattern interpolation.
- @sffc - Maybe these 4 crates:
icu_decimal(FixedDecimal formatting),icu_compact,icu_scientific,icu_*** - @Manishearth - Is there an umbrella term for currency and measurement units?
- @sffc - I think just "unit"
- @Manishearth - So we could name the crate
icu_unit. A problem with that though is if people plug in their own dimensionality libraries, a thing we might want to do is have our own unit library with a default implementation of it. So we might wanticu_unitto be that lower-level thing, and "icu unitted number formatting" - @markusicu - question
- @younies - Given the comments above, it seems fine to use one crate; what this thing does is formatting. So like
icu_formatter. But there are lot of crates that do formatting. Soicu_number_formatter? But that doesn't sell what the crate is doing, because it does more than just basic number formatting. - @sffc -
icu_decimalis low-level with notation support, including compact decimal, andicu_decimal_unitedcontains the kitchen sink including units - @sffc - We can make
icu_listbe an optional dependency of that kitchen sink crate - @younies -
icu_decimal_extended - @Manishearth - I'd kind-of rather have separate crates than optional dependencies for things like the list optional dependency. So what does the kitchen sink contain? Currencies, units, and combinations of them, including complex unit formatting.
- @sffc - is this going to contain rbnf when we do it
- @markusicu - why
icu_decimal? why noticu_number, or clearericu_number_formatting? and thenicu_units_formatter - @sffc - "icu_decimal" implies "decimal formatter" in the same way "icu_datetime" implies "datetime formatter" and "icu_list" implies "list formatter"
- @sffc - "decimal" is a bit better than "number" because it is more specific; "number" can include RBNF in the future.
- @younies - I think we should have
icu_measuresince it's more related to what we're actually formatting. Currencies are a form of measurement. - @Manishearth - It's an interesting concept. We format numbers in date and relative time. But relative time is the interesting one; relative time is a number. I'm not sure about
icu_measurebecause we have already been using that term for measurement units. - @Manishearth - For decimal and RBNF, does RBNF operate on decimals?
- @markusicu - RBNF supports other displays of numbers like spellout.
- @Manishearth - I imagine that an RBNF API will still take a FixedDecimal input. If so is
_decimalvs_numberreally the way we want to name the distinction - @sffc - regarding where we should land here: there's enough in the date/number space that is unique that we should have a separate crate containing all the things like relative time/etc. So i think it's fine to have a separate crate, maybe
icu_duration. - @sffc - regarding
icu_measurewe need to be clear about the namespace we are introducing. although icu4c uses the term to talk about a unit like cldr meters, that's not necessarily consistent. not necessarily incorrect to adopt the opposite convention, but we should be aware of that choice- - @markusicu - I prefer "unit" over "measure"; I think it's clearer
- @markusicu - I believe that RBNF can do roman numberals. I believe that RBNF is used for Hebrew-numbers-via-letters, for date formatting. I believe that RBNF could be used for base-20 numbers and Chinese numbers etc. --> I accept "decimal" vs. "number"
- @sffc - reiterate question of rbnf vs unit, are we going to want to do "IV days" or "five hundred and twenty miles". are we going to share data / separate code path?
- @markusicu - supposedly could have a generic number formatter. does get you into grammar issues with agreement and stuff
- @younies -
icu_quantity,icu_scale - @Manishearth - Seems like the RBNF+Unit is a path we may want to support in the future; it will need to be done carefully with agreement. But the idea of a generic number formatter in that case seems like it could work.
- @Manishearth - We already want the ability for scientific, compact, and fixed decimal formatting to be fed into the unit formatter
- @sffc -
icu_decimal,icu_number,icu_rbnf, (maybeicu_compact,icu_scientific) - @markusicu - RBNF roughly at that level but not in the same crate. Note that RBNF needs a lot more data regarding agreement.
- @sffc - For the crate name of the unit formatting crate:
icu_units,icu_united. I don't likeicu_unitbecause "unit" sounds like it should be small because that is what the word "unit" means. - @younies -
icu_younies - @Manishearth -
icu_dimensioned - @Manishearth - How about the thing that does unit conversions?
Options:
icu_numbericu_measureicu_uniticu_unitsicu_dimensionedicu_unitedicu_quantityicu_decimal_extended
- @younies - What is the problem with
icu_quantity? And thenicu_unitcontains the conversion, all the types. - @sffc - I'm warming up to it
- @markusicu - i think part of this is the discussion bw "just units and conversions" plus "this thing that does formatting". why not have a
_formattersuffix - @sffc choice that had also been discussed with ICU4X people incl Zibi.
icu_datetimeis the crate that does everything datetime related from an i18n perspective: which is formatting. We then split out calendrical calculations because they were sufficiently disjoint. For the other ones it's clean: casemap, segmenter, collator, duration, etc. The object that does the operation (the "formatter") is a member of the crate. Most importantly, though, we should re-litigate this at a different time than deciding the names of the unit formatting crate in the context of the existing convention. - @Manishearth - My concern with
icu_quantityis that it's not self-evident that it does unit formatting, which makes it less discoverable. - @sffc -
icu::quantity::SingleUnitFormatter - @sffc -
icu::units::SingleCurrencyFormatter,icu::units::SingleMeasureFormatter - @younies - And then we end up with
icu_unit_conversionwhich is fine I suppose. - @sffc - Are we doing quantity formatting or unit formatting?
- @Manishearth - "quantity formatting" is technically more correct.
- @sffc - I think we can make it discoverable. If people find
icu_unit, it should link toicu_quantityin the first paragraph of the docs. And same withicu_decimal.
Distilling to two options:
icu_units+icu_unit_convert[er/ion]icu_quantity+icu_unit[s]
Conclusion: Poll the greater ICU4X team between these two choices.
robertbastian
younies
Choose an appropriate name for experimental/single_number_formatter crate