l10n

[justinwb]

Different but similar to Internationalization (i18n), Localization (l10n) allows users to configure their locale, and have their applications render data differently based upon it. For example, in the US, dates are presented is MM/DD/YYYY, but in most parts of europe, it is DD/MM/YYYY. A United States locale would present the former, and a UK locale would present the latter.

[megoth]

We need to figure the level of l10n that we want to support. E.g. we could provide components that facilitate automatic conversion from metric system to imperial system, but that might come with a price of complexity we don't want to impose.

[brownhoward]

@megoth Agreed that that it would be nice to handle the automatic conversion between measurement units systems, but based on prior experience it is does add complexity as well as a performance overhead. In a prior life, I was part of a team developing a building automation system that was used worldwide so had to handle data in imperial, metric and even some non-standard measurement units systems. As a single client could have buildings in different countries that stored data in the measurement units system of the local country, we needed metadata about each data value including what units the data was it stored in and how to convert to other measurement units systems. As we were handling time series data at 5 minute interval, it was a significant performance hit to convert and aggregate data across a client.

(As an aside, the building automation system also had to handle time-stamped currency conversions which required storing historical currency exchange rates for a large set of global currencies which was another headache)