Extension talk:UnitsFormatter

Unit Names
One area which probably needs some work is in the names of units. For example, can we do something less cumbersome than "British gallons" and "US gallons", while still being unambiguous? One huge piece of nastiness in the unit table is the calories and BTUs. It would make sense to have one unit just called "calorie", but I could not find any evidence that there is one particular version which is predominant. Any ideas? JohanTheGhost 16:15, 21 June 2007 (UTC)


 * I would love it if you could include a user preference that allowed for always using the abbreviation instead of the full unit name for the primary unit. I administrate a wiki that has a lot of plant data with leaf measurements, and seeing the full names of centimeters and inches over and over makes the reading more cumbersome than seeing the abbreviations.  Overall, though, I love this extension!
 * --76.215.127.150 (WildeRix) 21:02, 13 July 2007 (UTC)

Parser Function
I think this extension would be useful as a Parser Function in addtion to (or instead of) an extension tag. The calling could be akin to  . This way you gain the ability to interpret template parameters and extend the functionality. -- Jimbojw 16:42, 21 June 2007 (UTC)


 * Aha! That nicety (interpreted parameters) had escaped me.  I actualy started with it as a function (   for 67 celcius, 1 digit, alternate units kelvin), but thought a tag would be less cumbersome.  Of course, I could call the parser to process the input at the beginning -- is a function more efficient than that?


 * Or how about:


 * ie.
 * scrap the "digits" parameter, just use the input precision (which I do by default anyhow)
 * alt units just specified as additional units (here us gal and litres)
 * second parameter for realm
 * ...? JohanTheGhost 18:27, 21 June 2007 (UTC)


 * Any progress with this? I'm working on a cooking wiki project at the moment, and being able to nest parser functions/access template parameters would really help (we're making all of our recipe amounts for single serves and then multiplying that by a template param to get the amount needed for how big the meal would be).
 * I'm also using DPL at the moment and rather than having explicit parameters when used in parser function mode, they do it like this (I haven't looked at the code yet, but I expect they split the string around the = and switch on the parameter name):


 * - Cheese 4th October 2007

Solution

 * I had a bit of a go at it, and I've got it up to where it does what I need. Here's the code:


 * Add this into __construct


 * And this wherever suits


 * I've not done any PHP before, so it may not be the most elegant way of doing it - eg: how efficient is trim in this sort of situation?
 * - Cheese 5th October 2007

Scaling
Any thoughts on converting the output to an appropriate unit in the native (author specified) measurement system? One of the things I needed a parser function for was so that I could convert values that were dynamically generated a template param.

eg:

It's all working fantastically, except that 80,000 grams would maybe be a bit superfluous. It'd be simple enough for metric to convert anything that returned true for (value / 100) > 1 to the next unit up, but non metric measurements would be a bit more complex.

- Cheese 5th October 2007