Change the name to be more related
Opened this issue · 11 comments
Smart Unit Preferences is kinda a fascinating name, especially the smart part. Therefore, if you have any suggestion would be nice :)
@sffc , @zbraniecki , @hugovdm ... could you add suggestions, please?
Based on LDML - http://unicode.org/reports/tr35/tr35-general.html#Unit_Preference_and_Conversion - maybe "NumberFormat Unit Preferences"?
Or just "Measurement Unit Preferences"?
I think Unit Preferences is enough, what do you think?
I would have liked "NumberFormat Unit Preferences" if that was all that we would propose with this.
There was some talk in the meeting about exposing just the preferences as a first step, and not implementing the conversions? Because of this, I'm feeling "Measurement Unit Preferences" is broader in scope and would have us covered even if we did end up "pivoting" away from [only] changing Intl.NumberFormat with this.
The problem with "Unit Preferences" is that it is easy to confuse with "User Preferences".
@hugovdm , I do not want to tight Unit Preferences with NumberFormat, because may be people will use some of the Unit Preferences stuffs without formatting such as conversion or just to know the preferences themselves ... etc.
Does it mean you intend for the API to be attached to Intl directly rather than Intl.NumberFormat?
The problem with "Unit Preferences" is that it is easy to confuse with "User Preferences".
I don't see this as an issue.
@hugovdm , I do not want to tight Unit Preferences with NumberFormat, because may be people will use some of the Unit Preferences stuffs without formatting such as conversion or just to know the preferences themselves ... etc.
Does it mean you intend for the API to be attached to
Intldirectly rather thanIntl.NumberFormat?
I'm primarily thinking of the request someone made: for us to consider providing an API that returns user preferences, before we consider adding an API that actually does all the conversions etc as well. I'm not convinced by this suggestion, but I'm appreciating some concerns about the complexity we're adding to the ECMAScript platform when we're going so far as to add unit conversions to it.
Recap: practically speaking, how do we relate to up-to-date ECMAScript implementations that don't make use of ICU? (Do they exist at this time, or is this hypothetical?)
-- This does go a bit off-topic, maybe we need a separate discussion thread for this?
Two examples of future non-ICU implementations are polyfills (such as format.js) and ICU4X.
for us to consider providing an API that returns user preferences, before we consider adding an API that actually does all the conversions etc as well.
That was me and the motivation is to continue with the tradition of ECMA402 being building blocks for user libraries that are intended to lower the entry barrier and payload per-website.
In this case, I'm not confident that the payload is high, and the use case is common enough to justify such API, but if it is, offering building blocks rather than end-to-end solution seems safer and less likely to backfire.
Recap: practically speaking, how do we relate to up-to-date ECMAScript implementations that don't make use of ICU? (Do they exist at this time, or is this hypothetical?)
-- This does go a bit off-topic, maybe we need a separate discussion thread for this?
I would consider it to be a failure of this WG if we ended up designing a spec that implicitly requires ICU backing.