[11:12:29] how is that function supposed to handle cases where the same word is used for multiple units? [13:26:14] i'm wondering the same! [13:26:15] when one say "mile" the most obvious and common unit for me is the nautical mile, not the British one or any on the thousands of unit with the name "mile". And even the British mile changed over time IIRC. (re @Nikki: how is that function supposed to handle cases where the same word is used for multiple units?) [14:30:50] I have mile, miles, and mi set to whatever 'Murica calls the mile and nautical mile, nautical miles, and NM set to nautical miles (re @Nicolas: i'm wondering the same! [14:30:51] when one say "mile" the most obvious and common unit for me is the nautical mile, not the British one or...) [14:31:45] 🤷 I have no strong opinions here (re @Nikki: how is that function supposed to handle cases where the same word is used for multiple units?) [16:52:06] These units should be eventually defined in some language-agnostic way, so that it's possible to convert, no matter what language the user uses for input. Even using standard SI symbols won't fix this, as some languages commonly use symbols coming from their alphabet, e.g. Russian will have мл, instead of ml for milliliter. Additionally [16:52:47] Additionally, there are many culture-specific units that won't have good English term to represent them [16:55:15] use Wikidata item IDs for those things [17:01:39] I'd go with defining persistent objects for units - they could contain how they are expressed in base units. This would separate data definition from the actual converter function. And this way, adding new units will be needed in only one place (instead of many, when there are multiple implementations of convert) [17:03:37] I would say we have this already, they’re called Wikidata items [17:03:40] Q7727#P2370 etc. [17:04:57] Oh, I didn't know there's such representation there. But makes sense [17:07:11] in RDF / SPARQL you even have access to normalized quantities (https://www.mediawiki.org/wiki/Wikibase/Indexing/RDF_Dump_Format#Normalised_quantity) (the conversion factors are exported from those Wikidata statements, though not livel) [17:14:36] I could have Wikidata items be aliases for the units? It sounds tedious to manually find all the IDs for the units I support, though (re @mahir256: use Wikidata item IDs for those things) [17:20:35] Right, but we can't exactly fetch this yet, T381207 (re @lucaswerkmeister: Q7727#P2370 etc.) [18:07:13] sure, so you can wait to create the function until the system is ready for it [18:07:29] (or, if you insist on creating it now, do what @mahir256 suggested) [18:07:54] I already have created the function (re @lucaswerkmeister: sure, so you can wait to create the function until the system is ready for it) [18:08:28] It works fine (and better than the on-wiki templates/modules) [18:08:51] Z21053 [18:10:17] I'm sure I'll get around to making Wikidata items work with it soon, it already has an alias system. [23:17:57] I actually think that we should only use metric abbreviations. A sample unit: kBMJ/ym3 is kilobyte joules per year per cubic meter (re @Feeglgeef: I'm sure I'll get around to making Wikidata items work with it soon, it already has an alias system.) [23:19:51] I think that we would have an internal function that accepts a rational number and does not care if the inputted units are of the same dimension and have an outer function that accepts decimal, full number, and rational representations and also makes sure the units are of the same dimension. [23:22:34] Also I propose this as a standard unit for the measurement of storage and energy usage per storage size space per year to compare data center efficiency :) (re @Feeglgeef: I actually think that we should only use metric abbreviations. A sample unit: kBMJ/ym3 is kilobyte megajoules per year per cubic...)