Closed younies closed 8 months ago
SingleUnitNumberFormatter
might work.icu_decimal
(FixedDecimal formatting), icu_compact
, icu_scientific
, icu_***
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 want icu_unit
to be that lower-level thing, and "icu unitted number formatting"icu_formatter
. But there are lot of crates that do formatting. So icu_number_formatter
? But that doesn't sell what the crate is doing, because it does more than just basic number formatting.icu_decimal
is low-level with notation support, including compact decimal, and icu_decimal_united
contains the kitchen sink including unitsicu_list
be an optional dependency of that kitchen sink crateicu_decimal_extended
icu_decimal
? why not icu_number
, or clearer icu_number_formatting
? and then icu_units_formatter
icu_measure
since it's more related to what we're actually formatting. Currencies are a form of measurement.icu_measure
because we have already been using that term for measurement units._decimal
vs _number
really the way we want to name the distinctionicu_duration
.icu_measure
we 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- icu_quantity
, icu_scale
icu_decimal
, icu_number
, icu_rbnf
, (maybe icu_compact
, icu_scientific
)icu_units
, icu_united
. I don't like icu_unit
because "unit" sounds like it should be small because that is what the word "unit" means.icu_younies
icu_dimensioned
Options:
icu_number
icu_measure
icu_unit
icu_units
icu_dimensioned
icu_united
icu_quantity
icu_decimal_extended
icu_quantity
? And then icu_unit
contains the conversion, all the types._formatter
suffixicu_datetime
is 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.icu_quantity
is that it's not self-evident that it does unit formatting, which makes it less discoverable.icu::quantity::SingleUnitFormatter
icu::units::SingleCurrencyFormatter
, icu::units::SingleMeasureFormatter
icu_unit_conversion
which is fine I suppose.icu_unit
, it should link to icu_quantity
in the first paragraph of the docs. And same with icu_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.
Voting here: https://docs.google.com/document/d/1AftqfMIFjgQAKpIfO8pmYMZW-KIOBtYkVHZuwgYcfsw/edit
@robertbastian will implement the result.
I ran four different ranked choice voting methodologies, which all produced different outcomes. So, we need to make a judgement. I observe that a majority of voters ranked icu_dimension
as their second choice. It got one first-place vote, two third-place votes, and no fourth or fifth place votes. This option is at least tied for the winning choice in every ranked choice voting algorithm except for Instant Runoff Voting (which favors candidates with first-choice votes, but we value consensus over a passionate subset).
I'll therefore declare icu_dimension
the winner of this horse race.
For the second question, it appears icu_units
wins; I was the only vote for the singular form.
Still renaming icu_unitsconversion
toicu_units
Choose an appropriate name for experimental/single_number_formatter crate