[Feature] Add INR (Indian Rupee) to supported currencies

[jay-tau]

Summary

Add INR (Indian Rupee) to the supported currency list, so Indian users can record flight costs in their local currency.

What problem does this feature solve?

The currency selector is currently limited to four codes — EUR, USD, GBP, CHF — enforced at three layers:

• Backend Zod schema: backend/src/schemas/flight.ts — currency: z.enum(['EUR', 'USD', 'GBP', 'CHF']).optional()
• Frontend type union: frontend/src/lib/units.ts — same 4-member Currency type
• Frontend store/options: frontend/src/store/settingsStore.ts — same union

For users in India, this means there's no honest way to log a flight cost: I either pick a wrong currency and end up with a display.units.currency = 'EUR' formatting ₹8,499 as €8,499, or I leave price empty and lose the cost-tracking feature entirely. Any user outside DE/CH/UK/US has the same problem — the four hardcoded currencies cover roughly 13% of global air-travel spend.

What do you propose?

Two options, in order of preference:

Option A — Drop the allow-list, accept any ISO 4217 code.

Intl.NumberFormat(locale, { style: 'currency', currency }) already supports every ISO 4217 code natively, so the existing formatCurrency() / getCurrencySymbol() lookup tables in frontend/src/lib/units.ts are doing work the runtime does for free. Concretely:

// backend/src/schemas/flight.ts
- currency: z.enum(['EUR', 'USD', 'GBP', 'CHF']).optional(),
+ currency: z.string().regex(/^[A-Z]{3}$/, 'Must be a 3-letter ISO 4217 code').optional(),

// frontend/src/lib/units.ts
- export type Currency = "EUR" | "USD" | "GBP" | "CHF";
+ export type Currency = string;     // ISO 4217 alpha-3

…and replace the hand-written localeMap / symbolMap with Intl.NumberFormat's built-in resolution (it already handles INR, JPY, AUD, CAD, SGD, AED, etc. correctly across every supported locale, including the ₹ symbol and Indian grouping 8,49,999).

This is one schema change, one type alias, and ~30 lines of dead code removed. The settings UI dropdown can stay (with INR added) or become a typeahead — either works.

Option B — Just add INR (and any other commonly-requested codes) to the allow-list.

Smaller diff if you want to keep the explicit allow-list:

// backend/src/schemas/flight.ts
- currency: z.enum(['EUR', 'USD', 'GBP', 'CHF']).optional(),
+ currency: z.enum(['EUR', 'USD', 'GBP', 'CHF', 'INR']).optional(),

// frontend/src/lib/units.ts
- export type Currency = "EUR" | "USD" | "GBP" | "CHF";
+ export type Currency = "EUR" | "USD" | "GBP" | "CHF" | "INR";

  const localeMap: Record<Currency, string> = {
    EUR: "de-DE", USD: "en-US", GBP: "en-GB", CHF: "de-CH",
+   INR: "en-IN",
  };
  const symbolMap: Record<Currency, string> = {
    EUR: "€", USD: "$", GBP: "£", CHF: "CHF ",
+   INR: "₹",
  };

Plus the matching addition in the settings dropdown UI.

Alternatives considered

• Pick the closest existing currency (USD). What I'm doing today as a workaround. Numbers in the dashboard are off by ~85× and the $ symbol is misleading — totally unusable for the cost-tracking feature it's meant to feed.
• Store the price unitless and put INR in the notes field. Loses the currency-aware formatting and breaks any future stats aggregation by currency.
• Patch the running container locally. Possible (the validation is plain TS), but a per-host fork that breaks on every upgrade isn't a real solution.

Notes

I'm in India and would happily test a build with INR added. If you go with Option A, the only behavioural risk I can think of is that Intl.NumberFormat's symbol for CHF is "CHF " with a trailing space (matching today's symbolMap) but defaults to a non-breaking space in some locales — unlikely to be visible but worth a quick visual check.

[Abrechen2]

Went with Option A as you suggested — Zod schema is now z.string().regex(/^[A-Z]{3}$/), the frontend Currency type is just string, and the manual symbol / locale maps are gone. Intl.NumberFormat handles INR / JPY / SGD / etc. natively, including the ₹ symbol and Indian grouping 8,49,999 out of the box.

The Settings dropdown got an evolution on top — replaced with a styled Combobox so users can type any ISO 4217 code directly (filters as you type, accepts arbitrary 3-letter codes like ISK or ZAR even when they're not in the suggestion list). Native <datalist> rendered too differently across browsers to keep.

Ships in v1.4 RC — i'll ping you here when the RC tag is up so you can verify INR formatting on a real Indian-locale browser.

Bigger picture: the whole Cost & Expense System is getting an overhaul in v2.2 — unified Expense model, FX-snapshot at entry time, Cost-Categories (ticket / tax / fee / ancillary / hotel / excursion), Payment metadata, per-trip Default-Currency. Currency-Input is the first piece, the rest follows after the v2.1 Frankfurter FX-Pipeline lands. Thanks for the clean breakdown!