Localization sounds simple, but it is not: Part 2 — Supporting multiple currencies

Full guide for localizing your application covering Translation, Currency, Global vs. Local content, UI adjustments and R&D culture.

This is the second post in the localization guide series. In this post will cover the second aspect of localization, which is supporting multiple currencies across the different locales.

Part 1: Translation

Part 2: Supporting multiple currencies (We are here)

Part 3: Serving Global vs. Local content (Not published yet)

Part 4: Handling UI adjustments (Not published yet)

Part 5: Creating localization aware R&D culture (Not published yet)

Currency

Your application might sells products, services or displays prices for any reason. You want to make sure that users will see these prices in their locale currency. Users who browse your site from France expect to see the prices in Euro, while those who browse from England expect to see pounds.

Before we dive into the importance of displaying the currency in its correct format, let’s first understand what is the correct type to use when working with prices in your code base.

int? double? decimal? Money?

What would be the best type for the price property of your product? It cannot be int since prices can have fractions. It might be double, however it is not best practice for prices.

How to decide what to use — double or decimal?

So we are left with decimal. It will allow us to easily display a 10.55 price. Hold on. 10.55 what? Dollar? Euro? NIS? Canadian dollar?

Price is not only a number. Price is a number with currency, so the best type for currency is actually an object that has both the amount and currency properties. You can implement it by yourself, however you need to remember that simply putting the currency sign is not enough. Every currency has its own format and display.

Currency Formats

Every currency has its own format and rules:

It might be very confusing for your users to see prices in wrong formats. Money is a very sensitive topic to the users, we don’t want to make them distrust our site due to wrong currency formatting.

Note the difference between using a dot and a coma

Etsy has a great post about the challenges of supporting and displaying currencies in their correct formats:

How Etsy Formats Currency

There are great open sources out there that solve this problem, like the one we’ve chosen — Noda Money.

remyvd/NodaMoney

It provides you both the Money object along with all the currency formats and also variety of Money arithmetical operations and casts.

Don’t perform pricing calculations in the client side

On of the biggest difficulties that we had while refactoring the code to support multiple currencies was pricing operations that took place in the client. Some javascript string manipulators like:

var price = 10 +’$’;

You need to avoid performing such operations in the client since it will be extremely hard to introduce other currency signs besides $ and exposing pricing calculation logic in the client is both dangerous and wrong, since it’s probably not the client’s responsibility to own the pricing logic. The server should be the only place where such logic happens.

Exchange rates

There is a good chance that your application will allow users to see items from different currencies. However you don’t want to present items with different currencies side by side, you’ll want to exchange the different item’s currencies to a single, locale relevant currency. In order to achieve that you’ll need to find the exchange rate and convert the $ into Euros. There is a simple and fast exchange API that is maintained by Google.

Foreign exchange rates and currency conversion JSON API

You can store the exchange rates in cache every ~10 minutes and use them for the price conversion to reduce API calls.

“Price is only approximate”

This is how exchanged prices are displayed on Ebay

Even if you exchange the prices using real-time exchange rates, the price is only approximate, since the actual final price is determined by the payment provider. Every provider has its own exchange rates — Paypal is different from your credit card company i.e.

By the way, as a user you should always pay using the local currency of the site, don’t let the site or PayPal do the conversion for you since they will usually have a higher exchange rate than your bank.

Avoid PayPal Money Transfer Currency Conversion Fees | CurrencyFair

Summary

Your need to get yourself ready for some refactoring in case you need to support multiple currencies. Avoid calculations in the client, make price an object with both amount and currency properties and use proven open source that handles all the different formats for you.

Localization sounds simple, but it is not:

Part 1: Translation

Part 2: Supporting multiple currencies (We are here)

Part 3: Serving Global vs. Local content (Go here — link will be added soon)

Part 4: Handling UI adjustments (Not published yet)

Part 5: Creating localization aware R&D culture (Not published yet)