currency-examples

Currency Examples

The following are real-world examples and brainstorming for marking up currency.

The Problem

The problem: how to explicitly specify a) that a figure/number relates to money; and b) the currency of a stated figure.

• The currency sign cannot be used reliably since the same sign (or symbol) may represent more than one currency. eg. $ is used for many different dollars (USD, AUD, CAD...) and even other units like pesos.
• The language of the page is not sufficient to define the currency of prices in the page:
  • More than one currency may be used by people who speak the same language.
  • The page may be written in one language and still quote prices/figures in a different country's currency.
  • Even if a country can be identified, more than one currency may be used in that country.

Converting currency figures is a reasonably easy problem to solve as indicated by the #Existing_Practices. However many automated conversion tools must make assumptions about the original figure's currency - eg. assuming a USD for all uses of $, or British Pounds for £ (which is also sometimes used to denote Lira).

Related problems

"Amounts" in arbitrary units is a bit harder and necessary for several applications.

For example, consider the work that has been done on a recipe microformat.

recipe-examples

Though we haven't reached this problem yet in the research, I can see it coming:

Say you wanted to create a "shopping list" application which you could tell which recipes you wanted to cook, and have it automatically total up all the various amounts of ingredients and give you the net amount of stuff you wanted to pick up.

It would need to be able to determine precise amounts/units of each ingredient. This might turn out to be like the currency problem, or it might be more complex, given the variety of units used in recipes, English vs. metric etc. That's a case that might need a microformat. We need more research and analysis to really justify it, but I can see it within the realm of probable possibility.

Participants

• Ben Buchanan
• Charles Iliya Krempeaux
• Ben Ward
• Arve Bersvendsen
• Mike Stickel
• Ciaran McNulty
• Tantek Çelik
• Steve Ganz

Real-World Examples

Links to public web pages, either popular or insightful

McAfee

<span class="price">$39.99 <span class="currency">(USD)</span></span>

Amazon

<td class="price">$34.85</td>

Bell Canada in French Canadian

<font size="larger"><b>Niveau de service Premium - 125 $*</b></font size>

Note the placement of the dollar sign AFTER the number.

Bell Canada in US English

<font size="larger"><b>Premium Service Level - $125*</b></font size>

Existing Practices

Firefox Extension

Firefox Currency Converter - ViewMyCurrency

Note: the current bug list illustrates some problems of identifying currencies based on page content alone:

• All $ symbols are treated as USD Very annoying if you are Australian, Canadian etc. (Needs a new feature)
• ‘Euro 2006 Championship’ should not be converted.
• ...
• Don’t convert CVS keywords . $Revision: 1.3 $ should not be treated as dollars.

Greasemonkey Scripts

Exchequer

Yahoo! Finance Currency Converter

Relevant Standards

ISO 4217 Codes

Brainstorming

Ben Buchanan

Verbose but extensible and explicitly defines all values (without breaking DRY):

<div class="currency">
  <p class="figure">
     <span class="code">code</span>
     <span class="sign">symbol</span>
     <span class="amount">12345</span>
  </p>
</div>

"figure" is there to both explicitly associate the code, sign and amount but also allow the potential for more than one currency figure to be placed within the container. It does anticipate further development though and is the most easily dropped item at the early stage.

Without figure:

<div class="currency">
     <span class="code">code</span>
     <span class="sign">symbol</span>
     <span class="amount">12345</span>
</div>

Super shortened, relying on the parser to identify everything via implied order/structure.

<div class="currency">ABC12345$</div>

Although the simplest solution, it has a notable vulnerability: some currencies have/had three-letter abbreviations for their currency sign, instead of a symbol. This would make it very difficult for a parser to accurately identify such a currency.

In addition, it should be noted that the order alone cannot be used to identify which parts are code, sign and amount; since many currencies are denoted with the sign after the number.

Super shortened, but specifying a currency code as a class:

<div class="currency ABC">12345$</div>

It defines...

1. we're talking about money - ISO standard implied,
2. we're talking about the USD variety,
3. we're talking fifty units of that money,
4. a parser could work out the numbers and the symbol.

The biggest limitation I can see for that shorthand is that the currency code is not displayed visibly to human readers. The currency code is useful information to viewers and ideally should be displayed.

Shortened (including dropping 'figure', but explicitly defining and displaying the currency code. This would allow a parser to treat any remaining numbers as the amount; and any remaining a-z or symbol as the sign:

<div class="currency">
  <span class="code">ABC</span>12345$</p>
</div>

Charles Iliya Krempeaux

Maybe something like...

Pay me <abbr class="currency" title="CAD">$</abbr>5.00 now!

Although something like the the following might be better...

Pay me <span class="money"><abbr class="currency" title="CAD">$</abbr>5.00</span> now!

But it might be more semantic salt than is considered necessary. Just having the abbr with the class-currency near a number might be good enough. But that's open for discussion though.

Ben Ward

Could pure HTML be sufficient?

<html lang="en-gb">
<p>My new T-Shirts cost £30, but it cost my friend in Canada <span lang="en-ca">$34</span></p> 
</html>

Arve Bersvendsen

<p lang="nb">Den kanadiske prisen på t-skjorten var <span class="currency CAD">34 $</span>.</p>

Mike Stickel

<span class="money"><abbr class="currency" title="CAD eng">$</abbr><span class="amount">5.00</span></span>

In this format the wrapping would be "money" or something similar followed by either the actual "amount" or the "currency", depending on what rules your country/language follows in regards to the order. Since there can be a difference between different languages within countries I thought it might be a good idea to include that in the "currency" definition of the formating, eg., "CAD eng" or "CAD fr". It could also give sites that list multiple languages a way to differentiate when they show multiple prices.

Ciaran McNulty

The only microformat that I've noticed currency units in is hListing, and that deliberately shies away from parsing the actual values because it's too free-form in most existing Listing formats.

My own preference would be for something like:

<p class="money">This item costs
  <span class="currency">GBP</span>
  <span class="amount">10.00</span>
</p>

Which with similar parsing rules to existing formats would also allow things like:

<p class="money">
  It'll cost you
  <abbr class="currency" title="50.00">fifty</abbr>
  <abbr class="amount" title="GBP">quid</abbr>
  , mate!
</p>

Or, a more complex example with multiple languages:

<p lang="en">Price:
<span class="money">
  <abbr class="currency" title="GBP">£</abbr>  
  <span class="amount">1,250.00</span> 
</span> 
<span lang="fr" class="money">
  (Prix:
  <span class="amount">1600,00</span>
  <abbr class="currency" title="EUR">€</abbr>
  )
</span>
</p>

See Also

• abbr-design-pattern