To completely remove multilingual locales and avoid any locale-related side effects, you need to clean them in several places in Service Studio. Removing “a localization module” (or just one locale entry) is not enough; the metadata and translations can remain in other modules and still affect how the app behaves.

Below is a checklist you can follow.

1. Remove Multilingual Locales from Every Module

Locales are defined per module, not per application. So you must check each module (especially all UI modules):

1. Open the module in Service Studio.
2. Go to the Data tab.
3. At the bottom, find the Multilingual Locales folder.
4. Right‑click it and:
   • Disable or delete all locales you no longer want (e.g., ar, ar-SA, etc.).
   • Ensure only the base language (e.g., en-US or pt-PT) remains, or even no multilingual locales at all if you want to abandon multilingual support. Multilingual Web Applications

Do this for:

• Main UI module(s)
• Reused UI libraries
• Common widgets/blocks modules (if they have locales enabled)

If a module still has an Arabic locale enabled, its resources can still be translated and loaded.

2. Remove / Disable Language Resources (Translations)

Even if you delete locales, translation files may still exist and be applied when a locale is set.

For each module:

1. In Data → Resources → Translations (or via Module → Export / Import Language Resources):
   • Ensure there are no lingering translation XLS or .resx files that you are importing with Arabic texts.
   • If they exist and you don’t want multilingual anymore, either:
     • Stop importing them, or
     • Clean the translation content for the unwanted locales and re-import.

Arabic content in these translation files is what shows up in the UI when that locale is active. Multilingual Web Applications

3. Search for Logic That Changes Locale

Even if you “removed” locales, if your logic is still setting a locale (e.g., SetCurrentLocale("ar")), OutSystems will try to use it and render whatever translations exist.

Use Search in All Modules for:

• SetCurrentLocale
• GetCurrentLocale

Check these common places:

1. OnSessionStart of the module:

   • If your app previously set a default language (e.g., Arabic) when session starts, remove or change that logic.
     Example to clean:

   OnSessionStart
      -> SetCurrentLocale("ar")   // REMOVE or change to your desired default
   

   How to change the default language of an application.

2. Layout blocks / common blocks:

   • Many apps set locale in the OnInitialize of a Layout or a global block so it runs for all screens. Remove SetCurrentLocale there, or change it to your base language. Setting default locale

3. Screen actions / button handlers:

   • For example, language switcher buttons or flags that call SetCurrentLocale("ar"). Remove those or adjust if you no longer support multiple languages.

If any logic sets an Arabic locale, the UI will still try to render Arabic, even if you think you’ve removed the locale from one module.

4. Check for URL-Based Locale Usage

OutSystems supports setting locale via query parameter:

• ?locale=ar
• ?locale=ar-SA, etc.

Make sure:

• You are not using links, redirects, or JavaScript that append ?locale=ar to URLs.
• If you previously used this to simulate languages in browser, remove those usages. Trouble using Multilingual Locale

5. Verify Static Entities and Translated Labels

If your Arabic text comes from Static Entities or other data, it may not be strictly “locale” but just data:

1. Go to Data → Entities.
2. For Static Entities:
   • Check the Label (and similar fields) for globe icon (multilingual enabled).
   • Turn off Use Translations in advanced properties if you don’t want multilingual.
3. If the Arabic text is stored directly in database records (dynamic data), you must:
   • Update those records, or
   • Stop selecting/displaying the Arabic fields.

Multilingual Web Applications

From your screenshot, the Arabic strings in the filter popup could come from:

• Translated UI texts (labels, buttons) via multilingual resources, or
• Static/dynamic data stored in Arabic.

6. Clean Up Translated Images (If Any)

If you used locale-specific images:

1. In Interface → Images:
   • Right-click images and check if they have localized variants (e.g., Arabic version).
   • Remove localized images or reset their Locale property to your base language.

Otherwise, the app may still show localized graphics even after locale changes. Multilingual Web Applications

7. Confirm the “Final” Default Language

Once you’ve removed all locale references:

1. Decide what should be the final default language (e.g., en-US).
2. Optionally, set it explicitly in only one place:
   • Either in OnSessionStart or in the global layout OnInitialize:

   SetCurrentLocale("en-US")
   

   and ensure there’s no other SetCurrentLocale anywhere else. How to change the default language of an application.

If Issues Still Persist

If after this cleanup you still get Arabic texts:

• Use Find (Ctrl+F) in Service Studio with the Arabic word(s) that appear (e.g., one of the labels in your popup):
  • If they show up in a Screen / Block / Static Entity, it means they’re hard-coded or in a translation resource.
• Check all modules in the application, not only the one where you removed the localization.

If you describe where the Arabic still appears (e.g., only on one popup, only on a particular table, or after certain navigation), I can help you pinpoint whether that is coming from translations, static entities, or explicit SetCurrentLocale logic.