Units formatting Data Skeleton Design

[younies]

Issue Summary

We need to decide on our approach for units formatting data representation related to:

1. Splitting formatting data by locale only vs. locale and unit type (e.g., "en" vs. "en" & "meter").
2. Using different data skeletons for short & narrow formats vs. a uniform structure for all.

Questions

1. Locale Splitting: Should we split formatting data per locale or combine locale with unit type for more granularity?
2. Data Skeleton: Do we opt for different skeletons for format variations (short & narrow vs. full) or keep a uniform approach?

Request for Input

Please provide feedback on:

• Preferred strategies for both issues.
• Considerations regarding implementation complexity, performance, and maintenance.

Your insights will guide our decision-making process.

link to the doc

[sffc]

Discuss with:

• @younies
• @sffc

Optional:

• @Manishearth

[sffc]

My main question here is whether we want the lengths to be in aux keys or data keys.

[sffc]

We are doing data keys for list but aux keys for datetime. I think the use case is different: in datetime, the length is determined by the locale, but for list, the length is determined by the programmer. I think the length in unit formatting is more likely to be like list, so we should consider putting these in the key.

This would result in keys such as

• UnitNamesTimeShort
• UnitNamesTimeLong
• UnitNamesDistanceShort
• UnitNamesDistanceLong
• UnitNamesSpeedShort
• UnitNamesSpeedLong

(also with narrow)

And then an API for formatting "short speed" should include UnitNamesSpeedShort, UnitNamesTimeShort, and UnitNamesDistanceShort.

[Manishearth]

Is this still a 2.0 blocker?

[sffc]

Is this still a 2.0 blocker?

No.