(C) 20120 sussenburger.com
Simple guidelines for currency handling
Processing and display of currencies are crucial functionality in many applications, for example, for purchasing, inventory control, accounting, etc. NOTE: Data types used in databases to store numeric values (aka. "amounts") associated with currency processing are outside of the scope of this document. Application design must follow customer industry precision and rounding standards.
In a software application, a currency can be represented in several ways:
Note: Obsolete or deprecated currency symbols and names must not be confused with
the usage of the terms "obsolete" or "deprecated" in general coding. Obsolete currencies
may continue to be around in records management, accounting, banking, etc. Codes,
IDs, and names to use Use ISO 4217 currency names, alphabetic codes and numeric codes
in software: http://www.iso.org/iso/support/faqs/faqs_widely_used_standards/widely_used_standards_other/currency_codes/currency_c odes_list-
English names and codes used by banks can be found, for example, at http://www.lloydstsbcorporatemarkets.com/glossary/currencies.asp
A good source for additional obsolete codes is: http://en.wikipedia.org/wiki/ISO_4217 Applications may have to be able to use obsolete codes but this may cause additional translatability issues.
You can augment these with data from the Unicode CLDR project. If there is a conflict with ISO 4217, use ISO 4217 because this is what the money industry (banks, brokers, etc). uses. Major programming languages and API (for example, JAVA, Windows API) use ISO 4217.
Application designers must ensure that display names are unique. The best way to achieve this is to add the ISO 4217 alphabetic code to selection options.
Use this: US Dollar (USD)
Do not use this: US Dollar
As a matter of fact, there are three codes related to US Dollar: USD, USS, USN see ISO 4217 for details.
You can use currency symbols for display, for example, in an invoice: $ 40.47. However, currency symbols as labels by themselves MUST NOT be in translatable files.
Extract to untranslatable file: Yes
Extract to translatable file: No, for eample, the yen symbol by itself: Y
Extract with context: Yes, for example, the dollar symbol followed
by the name: $ (US Dollar)
While a currency is often tied to a country, software applications will usually need to provide a way to configure the display and use of currencies.
Main reasons for the need to allow configuration:
The numeric values displayed to users must be formatted in accordance with the user's
locale. The decimal symbol and the grouping separator must follow the user locale.
Never enforce formatting based on your notion of what the "default" format based
on the currency name would be. For example, USD 22,00 would be the expected format
to use in Germany -
All displayed "names" of currencies must be treated as "labels" in terms of software design and coding. In other words, if a display in a dropdown contains "U.S. Dollar" and the user can select "U.S. Dollar", the actual selection must be based on a unique identifier that is not ""U.S. Dollar" but the numeric ISO 4217 value 840 or the ISO 4217 code USD.
Obsolete currencies can cause naming collisions. Given that storing user interface strings in a database is extremely common in enterprise software, you will almost certainly run into currency label issues at some point.
This is especially true if you place "constraints" on label columns solely for the purpose of checking that labels are unique. Since currency labels are generally exported to a file to get translations, checks for duplicate translations should be performed at the file level.
If duplicate strings (labels) cause an application runtime error, the initial application design is flawed.