I was looking at a project recently where the client wanted to expand their store into the EU market. They had a high-end mechanical keyboard priced at 1250.50. Initially, they were just using number_format(), and it looked fine for their US customers. But once we started targeting Germany and France, it became obvious that we were doing it wrong. Let's walk through why and how to actually fix it.

The "Good Enough" approach fails

If I just want to put a couple of commas in a number, number_format() is my go-to. It's fast and it works. Let's try to format our keyboard price for a US user:

$price = 1250.50;
echo "$" . number_format($price, 2); 
// Output: $1,250.50

That looks great. But here is the problem: in Germany, they use a dot for the thousands separator and a comma for the decimal. Also, the currency symbol usually goes at the end. If I try to "hack" this with number_format(), I have to manually pass the decimal and thousands separators as arguments:

echo number_format($price, 2, ',', '.') . " €"; 
// Output: 1.250,50 €

Now, that works for Germany. But what happens when we add France? Or Japan? Or Brazil? I can't possibly write a giant switch statement that manually defines the separators and symbol placements for every country on earth. That's a maintenance nightmare. I need the system to "know" the rules based on the locale.

Bringing in the NumberFormatter

This is where the intl extension comes in. Specifically, the NumberFormatter class. Instead of me telling PHP how to format the number (commas here, dots there), I tell PHP who the number is for, and let the ICU library handle the rules.

Let's try to instantiate one for the US first:

$fmt = new NumberFormatter('en_US', NumberFormatter::CURRENCY);
echo $fmt->formatCurrency(1250.50, 'USD'); 
// Output: $1,250.50

Okay, that's basically what I had before. But watch what happens when I change the locale to German (Germany) without changing any other logic:

$fmt = new NumberFormatter('de_DE', NumberFormatter::CURRENCY);
echo $fmt->formatCurrency(1250.50, 'EUR'); 
// Output: 1.250,50 €

See that? I didn't tell it to move the symbol to the end or swap the comma and dot. The NumberFormatter knows that for de_DE, that's the legal way to display money. It's much cleaner because the business logic (the price) is separated from the presentation logic (the locale).

Handling the currency shift

One thing that tripped me up when I first used this was assuming the locale and the currency are the same thing. They aren't. A user in the US might be browsing a Japanese store. They are in the en_US locale, but they want to see the price in JPY.

Let's see how that looks:

$fmt = new NumberFormatter('en_US', NumberFormatter::CURRENCY);
echo $fmt->formatCurrency(1250.50, 'JPY'); 
// Output: ¥1,251

Wait, why is it 1,251? Where did the .50 go? If you've ever dealt with Yen, you know that it's a "zero-decimal" currency. You don't really have "cents" in Yen. The NumberFormatter is smart enough to know that JPY doesn't use decimals and rounds the value accordingly. number_format() would have just printed ¥1,250.50, which would look amateur to anyone actually living in Japan.

Plain numbers, different rules

Sometimes we aren't dealing with money—maybe it's a shipping weight or a distance. We still want locale-awareness, but without the currency symbols. For that, we use the DECIMAL style.

$weight = 1250.50;
$fmt = new NumberFormatter('fr_FR', NumberFormatter::DECIMAL);
echo $fmt->format($weight); 
// Output: 1 250,5

Notice the French formatting: they often use a non-breaking space as a thousands separator. Again, I didn't have to look that up or hardcode a space character; the locale definition handled it. If you're building anything that will be seen by people outside your own zip code, this is the only way to handle numbers. It saves you from a lot of "Why is the price formatted weirdly?" support tickets.

📋 Practical Task

Exercise: The Global Inventory Price-Tag Generator

You are building a tool for a warehouse manager who needs to print price tags for items being shipped to three different regions. You need to create a script that takes a single product price and a set of destination configurations and prints the correctly formatted currency string for each.

Requirements:

• Create an array called $destinations. Each element should be an associative array containing a locale (e.g., 'en_US', 'de_DE', 'ja_JP') and a currency (e.g., 'USD', 'EUR', 'JPY').
• Set a variable $itemPrice = 2499.99;.
• Loop through the $destinations array. For each destination, instantiate a NumberFormatter using the provided locale and the NumberFormatter::CURRENCY style.
• Print the result in the format: "Locale [locale]: [formatted_price]".

Expected Output should look similar to:
Locale en_US: $2,499.99
Locale de_DE: 2.499,99 €
Locale ja_JP: ￥2,500