[Due for payment 2025-11-13] [$250] Mweb- specially symbols after WST) are not correctly displayed on mWeb chrome

[nlemma]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: V9.1.83-4
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail: https://github.com/Expensify/Expensify/issues/268061
Email or phone of affected tester (no customers): na
Issue reported by: Applause Internal Team
Device used: Mweb/ Chrome
App Component: Money Requests

Action Performed:

1. Open the link staging.new.expensify.com
2. User logged in with account
3. Navigate to DM chat
4. Click + next to compose box >> Select "Pay user"
5. Click currency >> Select XPF (observe the currency is displayed XPF, instead C FPF)
6. Click currency >> select XOF (observe the currency is displayed XOF instead of CFA )
7. Click currency >> select XCD (observe the currency is displayed XCD instead of EC$ )
8. Click currency >> select XAF (observe the currency is displayed XAF instead of FCFA)

Expected Result:

Symbol for XAF should be FCFA, XCD symbol should be EC$, XOF symbol should be CFA and XPF symbol should be CFPF

Actual Result:

Symbols are not correctly displayed, they are same as name of currency for XAF, XCD, XOF, XPF on mWeb chrome android

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Bug6893900_1753086436689.MWEB.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021947462009266871573
• Upwork Job ID: 1947462009266871573
• Last Price Increase: 2025-07-22

Issue Owner

Current Issue Owner: @jliexpensify

[melvin-bot]

Triggered auto assignment to @kadiealexander (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[mohammadjafarinejad]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Symbols are not correctly displayed, they are same as name of currency for XAF, XCD, XOF, XPF on mWeb chrome android

What is the root cause of that problem?

We use the browser’s Intl.NumberFormat to get the currency symbol. On some platforms (especially mobile), this API doesn’t know the right symbol for certain currencies and just returns the code.

App/src/libs/CurrencyUtils.ts

Lines 52 to 58 in dfa504a

	function getLocalizedCurrencySymbol(currencyCode: string): string | undefined {
	const parts = formatToParts(IntlStore.getCurrentLocale(), 0, {
	style: 'currency',
	currency: currencyCode,
	});
	return parts.find((part) => part.type === 'currency')?.value;
	}

On mobile, this returns "XPF" for XPF, but on desktop it returns "CFPF".

What changes do you think we should make in order to solve the problem?

If Intl.NumberFormat returns the code instead of a symbol, we should fall back to our own currency symbol mapping (from our currency list).
So, update getLocalizedCurrencySymbol to:

function getLocalizedCurrencySymbol(currencyCode: string): string | undefined {
    const parts = formatToParts(IntlStore.getCurrentLocale(), 0, {
        style: 'currency',
        currency: currencyCode,
    });
    
    const intlSymbol = parts.find((part) => part.type === 'currency')?.value;

    // If Intl returns the code itself, fallback to our own mapping
    if (!intlSymbol || intlSymbol.toLowerCase() === currencyCode.toLowerCase()) {
        return getCurrencySymbol(currencyCode);
    }
    return intlSymbol;
}

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

• Test that getLocalizedCurrencySymbol('XPF') returns "CFPF" on all platforms.
• Same for XAF → "FCFA", XOF → "CFA", XCD → "EC$".

What alternative solutions did you explore? (Optional)

[Burhan-Rashid]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Mweb- specially symbols after WST) are not correctly displayed on mWeb chrome

What is the root cause of that problem?

The issue arises from a platform-specific behavior of the JavaScript Intl.NumberFormat API when using formatToParts() with style: 'currency'. On mobile web, Intl.NumberFormat sometimes does not return the correct localized currency symbol and instead returns the currency code itself. This discrepancy is due to limited or inconsistent Intl locale data on some Android web runtimes, particularly affecting "non-standard" or regional currencies.
We are using getLocalizedCurrencySymbol here:

App/src/components/TextInputWithCurrencySymbol/BaseTextInputWithCurrencySymbol.tsx

Line 31 in dfa504a

const currencySymbol = getLocalizedCurrencySymbol(selectedCurrencyCode);

and on some mobile web devices, this return us the currencyCode instead of the currencySymbol for some "non-standard" or regional currencies.

App/src/libs/CurrencyUtils.ts

Lines 52 to 58 in dfa504a

	function getLocalizedCurrencySymbol(currencyCode: string): string | undefined {
	const parts = formatToParts(IntlStore.getCurrentLocale(), 0, {
	style: 'currency',
	currency: currencyCode,
	});
	return parts.find((part) => part.type === 'currency')?.value;
	}

What changes do you think we should make in order to solve the problem?

We need to add a update this function so that there is a fallback when the for these type of currencies:

function getLocalizedCurrencySymbol(currencyCode: string): string | undefined {
    const parts = formatToParts(IntlStore.getCurrentLocale(), 0, {
        style: 'currency',
        currency: currencyCode,
    });
    const symbol = parts.find((part) => part.type === 'currency')?.value;
    // If Intl returned currencyCode itself as symbol (e.g. 'XOF'), fallback
    if (!symbol || symbol.toUpperCase() === currencyCode.toUpperCase()) {
        return getCurrencySymbol(currencyCode);
    }

    return symbol;
}

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

N/A

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[bernhardoj]

Proposal

Please re-state the problem that we are trying to solve in this issue.

The currency symbols is different between desktop and mobile web for some currencies.

What is the root cause of that problem?

We had this issue before, and the root cause is that the mobile browser is missing the locale for the currencies. The solution is to apply a number format polyfill. We still have the polyfill.

App/src/libs/IntlPolyfill/polyfillNumberFormat.ts

Lines 25 to 35 in 309bc78

	export default function () {
	if (Intl && 'NumberFormat' in Intl && !hasOldCurrencyData() && hasFormatToParts()) {
	return;
	}
	require('@formatjs/intl-numberformat/polyfill-force');
	// Load en & es Locale data
	require('@formatjs/intl-numberformat/locale-data/en');
	require('@formatjs/intl-numberformat/locale-data/es');
	}

However, the Intl.NumberFormat is memoized first before the polyfill is applied.

App/src/libs/NumberFormatUtils/index.ts

Lines 6 to 16 in 309bc78

	initPolyfill();
	const MemoizedNumberFormat = memoize(Intl.NumberFormat, {maxSize: 10, monitoringName: 'NumberFormatUtils'});
	function format(locale: Locale | undefined, number: number, options?: Intl.NumberFormatOptions): string {
	return new MemoizedNumberFormat(locale ?? CONST.LOCALES.DEFAULT, options).format(number);
	}
	function formatToParts(locale: Locale | undefined, number: number, options?: Intl.NumberFormatOptions): Intl.NumberFormatPart[] {
	return new MemoizedNumberFormat(locale ?? CONST.LOCALES.DEFAULT, options).formatToParts(number);
	}

We already applied the solution to it by running the polyfill before the memoization, but only applied it to iOS, even though this happens to other platforms too (including desktop web).

App/src/libs/NumberFormatUtils/intlPolyfill.ios.ts

Lines 3 to 8 in 309bc78

	// On iOS, polyfills from `additionalSetup` are applied after memoization, which results in incorrect cache entry of `Intl.NumberFormat` (e.g. lacking `formatToParts` method).
	// To fix this, we need to apply the polyfill manually before memoization.
	// For further information, see: https://github.com/Expensify/App/pull/43868#issuecomment-2217637217
	const initPolyfill = () => {
	intlPolyfill();
	};

What changes do you think we should make in order to solve the problem?

Instead of applying the polyfill before the memo only on iOS, we can do it on all platforms. So, we won't need this anymore

App/src/libs/NumberFormatUtils/index.ts

Lines 4 to 6 in 309bc78

	import initPolyfill from './intlPolyfill';
	initPolyfill();

and instead we need to call intlPolyfill.

intlPolyfill();

(also remove intlPolyfill from setup.ts)

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

We can create a test for getLocalizedCurrencySymbol with currency like XPF and make sure it returns the correct symbol.

[kadiealexander]

Android <> iOS swap!

[jliexpensify]

Going to tag in @Expensify/design so they're aware and can confirm what spacing is needed (if required)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~021947462009266871573