One booking app, two messages, then currencies
A travel booking app sends each customer a confirmation and a payment reminder, and both show a price and a travel date in the customer’s locale. Like the lesson’s page and stylesheet, the price format and the date format must come from one family. The team keeps one setting, the default locale, for customers whose own locale has no formats yet. Each level starts from the previous level’s finished code, so you can begin at any of them.
Sales wants each booking billed in the customer’s currency. A teammate’s pull request adds a currency to each booking and, to keep price formats inside the families, makes one family per language and currency the app bills in today: en-EUR, en-USD, de-EUR, fr-EUR and fr-CHF. A combination with no family falls back to the default locale’s euro family. Finance plans to add pounds and Swedish krona next quarter. You are reviewing the pull request.
A booking whose combination has no family shows the right amount in the wrong currency, in another locale’s formats. Every new currency would need a new family for every language.
Reproduce confirmationLine for a German (de) booking in USD should read “B-31 confirmed: 42,00 USD, travelling 03.11.2026”; today it reads “EUR 42.00, travelling 3 Nov 2026”.
Acceptance criteria A booking in any currency shows that currency in its locale’s price format: en “USD 42.00”, de and fr “42,00 USD”. A currency the app has never billed in works without a code change. Each message still takes both formats from one locale family, and a region tag still gets its language’s family. A locale with no family still gets the default locale’s family, in the booking’s own currency. Notes Cases print the message. Currencies are three-letter codes, printed as given. Keep the two messages’ names and signatures and the Booking type; the checker calls them. The rest is yours to change.