Quick Summary: Your extension didn't take over the UI language — it just filled in a previously-missing match for users on "Windows Default." Have affected users explicitly pick English under My Settings → Language, and that will stick regardless of the Arabic extension being installed.
1. How to switch the UI back to English
Go to the gear icon (⚙️) → My Settings → General tab → Language field → select English (United States) (or your preferred English variant) explicitly from the dropdown → OK.
The important word is explicitly. If the Language field is currently set to (Windows Default) rather than a named language, that's almost certainly the root cause of what you're seeing — see point 3 below.
2. Is there a setting in My Settings → Language?
Yes — My Settings → Language is a per-user setting (stored on the User Personalization record) and it's the correct, supported place to control UI language. It's independent of any extension. Selecting an explicit language there should always take effect immediately after the page reloads, regardless of what language extensions are installed.
3. Can a custom language extension override the user's selected UI language?
Not directly — an extension cannot silently force-change a user's saved language preference. But it can change what happens when a user's preference is set to (Windows Default):
Before your Arabic extension was deployed, Arabic wasn't a "known" culture in the tenant, so any user whose browser/OS locale reported ar-* would fall back to English (the base application language).
After deploying your extension, ar-* is now a valid, matching culture — so those same users (still on "Windows Default") now resolve to Arabic instead of falling back to English.
So the extension didn't override anyone's choice — it just made a previously-unavailable match now available. That's why explicitly picking English in My Settings fixes it: an explicit choice always wins over the Windows Default fallback.
4. Do you need to change anything in your .xlf files or app.json?
Not to fix the language-switching behavior — that's a runtime/user-setting issue, not a translation-file issue. A few things worth double-checking in your extension regardless:
app.json should have "features": [ "TranslationFile" ] so XLIFF generation/consumption works as expected.
Your .xlf file should live under a Translations folder in the extension root, named something like <ExtensionName>.ar-SA.xlf, and target only the ar-SA (or appropriate Arabic) culture — don't accidentally target en-US in that file, or you could overwrite English captions with Arabic ones.
Remember translations are applied in layers (base app → your extension → any other installed language apps). If multiple layers touch the same culture, the last one applied for that specific culture wins — it won't affect other cultures like English.
5. Recommended way to support both Arabic and English
Ship one .xlf per target culture (e.g., MyExt.ar-SA.xlf) inside the Translations folder — don't try to make Arabic the "only" language.
Never modify or remove the base English captions/labels — let English continue to come from the base application layer.
Let users choose their language explicitly via My Settings → Language rather than relying on Windows Default, especially in a bilingual/mixed-locale environment — this avoids exactly the surprise you ran into.
If the need is really about documents (invoices, orders, etc.) rather than the whole UI, use the Customer/Vendor Language Code field so documents print in the recipient's language without touching the sender's UI language at all. Since Business Central 23, you can also override the language/region on individual report runs from the report request page, without changing any user or system default.
If you want Arabic to be the default only for specific users (not the whole tenant), set it per-user in My Settings rather than at a company-wide level.
Hope you find your answer.
