You can get quite close to what you want, but OutSystems O11 doesn’t provide a fully automatic, framework-level “locale segment” router for Reactive apps today. You need to combine:

• SEO Friendly URLs (Service Center)
• Reactive’s built-in multilingual support
• Some custom logic (e.g. “router” screens / modules and JavaScript pushState)

Below I’ll address your questions point-by-point and outline practical patterns that are being used in the field.

1. Does OutSystems 11 support locale-based URL paths like /en-us/module/page?

OutSystems 11 supports SEO Friendly URLs and screen aliases, including for Reactive Web Apps (in recent versions of Service Studio / Platform Server 11). This gives you control over the path part of the URL, but it does not natively provide:

• A per-locale router that automatically maps /en-us/... vs /pt-pt/... to different content; or
• An out-of-the-box “locale segment” variable in the route.

You can, however, configure SEO rules so that:

• /en-us/store/product maps to a specific screen in a module
• /pt-pt/store/product maps to the same or another screen/module

…and then use the URL (or an SEO rule parameter) to determine the locale and set the language.

For traditional web apps this has been supported for a long time using SEO rules and aliases. For Reactive apps, SEO Friendly URLs are available but still have some limitations and require more manual configuration, especially around “root application” and site rules.OutSystems_Platform_SEO_Friendly_URLs

2. Recommended implementation approach if supported / partially supported

A typical pattern for a self‑managed O11 environment:

2.1. Use SEO Friendly URLs with a Traditional “Router” (Broker) App

Because SEO site rules and domain routing are better supported on traditional web modules, a common approach (even mentioned by OutSystems R&D) is:

1. Create a small Traditional Web application that acts as a router (or broker).

   • Its default screen:
     • Parses the incoming URL, extracts /locale/...
     • Sets the locale (and optionally stores it in Session / Site Property / cookie)
     • Redirects to the corresponding Reactive app URL (optionally passing locale via query string or path).

2. Configure SEO rules / Site Rules in Service Center:

   • Map domain + path patterns like /en-us/..., /pt-pt/... to the router app’s default screen (or specific router screens).
   • Within the router, decide which Reactive app + screen to redirect to.

3. In your Reactive app:

   • Read the passed locale (e.g., from query string or a path parameter if you encode it in the redirect).
   • Use OutSystems built-in multi-language features to set the locale/language.
   • Optionally use the locale to choose region-specific content or site properties.

This is essentially the workaround described by Tiago Simões (OutSystems) when SEO for Reactive was still incomplete.SEO Friendly URLs not supported with Reactive Web Apps?

2.2. Direct SEO Friendly URLs with Reactive (no broker)

With the newer technical preview of SEO Friendly URLs for Reactive apps, you can:

• Define Screen Aliases in Reactive modules, e.g.:

  • en-us/store/product
  • pt-pt/store/product

• Use SEO rules to map domain + alias combinations.

However:

• You will likely need to create separate aliases per locale or per region (no single dynamic {locale} segment that is automatically bound).
• Your app needs to infer locale from the alias (e.g. first segment) and set the language.

This is more manageable if you keep a small number of languages/regions and define a convention (e.g., alias pattern: {locale}/store/product).

3. Recommended approach if not fully supported / self-managed environments

Given you’re on self-managed O11 and have full control over infrastructure and Service Center:

1. Decide where you want to do the routing:

   • Option A: Traditional “router” app + SEO rules (most flexible).
   • Option B: Pure Reactive + SEO aliases (simpler, but less dynamic).

2. Implement URL → Locale mapping:

   • Design a convention: first path segment is {locale}.
   • In router or in Reactive, read this segment and map to a locale code used by OutSystems language configuration (en-US, pt-PT, fr-FR, etc.).

3. Set locale / language in OutSystems:

   • Use the built-in multi-language support for Reactive apps (static texts, resources) and set per-request language from the resolved locale.
   • Store locale in Session, cookie, or client-side variable to avoid having to re-resolve on every navigation (though for SEO it’s important that paths remain locale-specific).

4. Hreflang and SEO:

   • Build sitemaps listing your /en-us/... and /pt-pt/... pages.
   • Insert hreflang <link rel="alternate" hreflang="..." href="..."> tags in your layouts, using the known URL pattern for each locale.
   • Ensure localized content (meta-tags, titles, body) is actually language-specific.

4. Preserving the locale segment automatically across navigation

This is one of the harder parts in Reactive because navigation is client-side:

Option 1: Always navigate using full SEO-friendly paths

• When using links/buttons, always navigate to aliases that include {locale} in the path.
• You can create a centralized client action like GetCurrentLocalePathPrefix() that returns /en-us or /pt-pt, and build URLs accordingly.

Option 2: Use JavaScript history.pushState() for cosmetics

• As Tiago Simões mentioned, some teams use history.pushState():
  • Navigate internally using the “technical” URL (e.g. /Store/Product?id=...).
  • Immediately push a “pretty” localized URL /en-us/store/product/... into the browser’s address bar.
• This does not change what OutSystems thinks the URL is; it’s purely cosmetic, so you must handle reloads and direct hits carefully.

Option 3: Session-level locale + minimal path

• Keep locale in session or cookie and let the path be just /store/product.
• This fails your strict requirement for unique paths per locale, but is the simplest.
• If you can’t relax this requirement for SEO, this option is not enough.

5. Official documentation / best practices / references

OutSystems has documentation on:

• SEO Friendly URLs (primarily for traditional applications, but concepts carry over):
  OutSystems_Platform_SEO_Friendly_URLs

• SEO Friendly URLs for Reactive Web Apps – Technical Preview (forum announcement and discussion with examples and limitations):
  Technical Preview - SEO Friendly URLs for Reactive Web Apps

• Multilingual / multi-tenancy routing patterns (for tenant routing via SEO rules; concepts similar to what you want for locale):
  OutSystems Multitenancy Masterclass – Tenant Router and SEO-Friendly URLs

There isn’t yet a full “reference architecture” specifically for locale-based paths in Reactive SEO, but the tenant router pattern is almost identical: instead of /r/{tenantName}/{applicationName}, you use /locale/module/page and treat locale as a “tenant-like” selector.OutSystems Multitenancy Masterclass – Tenant Router and SEO-Friendly URLs

6. Known limitations for Reactive in format /locale/module/page

Key limitations / considerations:

• Dynamic segments: No first-class concept of a dynamic {locale} segment that is automatically bound to language; you must code that part yourself.
• Root application / site rules for Reactive: historically oriented towards traditional apps; requiring a broker is still a common practice.
• Technical Preview status: SEO Friendly URLs for Reactive might not cover all scenarios yet (e.g. complex site rules with multiple domains and locales).

These do not “prevent” the URL pattern /locale/module/page, but they mean extra work and possibly a thin traditional layer for routing.

7. If locale-based path routing is not fully supported, what is the recommended OutSystems approach?

From OutSystems’ own R&D responses and existing documentation, the de facto recommended approach in O11 for complex SEO scenarios (multi-domain, multi-region, multi-locale) is:

• Use SEO Friendly URLs + a small Traditional routing application, which:
  • Handles domains and path segments;
  • Determines localization (locale, region);
  • Redirects to Reactive modules/pages as needed.

Then:

• Use Reactive’s multilingual features for actual translations.
• Use standard SEO practices (sitemaps, hreflang tags, consistent URL structures) on top.

This aligns well with Google’s requirement for unique URLs per language/region, with the router ensuring those URLs exist and respond with the correct localized content.

Summary

• OutSystems O11 does not yet offer a native, fully automatic /locale/module/page router for Reactive apps.
• You can achieve such URLs through SEO Friendly URLs + aliases, combined with:
  • A traditional router app; or
  • Reactive SEO aliases with custom locale handling.
• Locale preservation across navigation requires careful design (alias conventions, URL generation helpers, and possibly pushState).
• OutSystems’ recommended pattern for complex routing is the SEO + router (broker) approach, which can be adapted to locale-based paths just like tenant-based paths.

If you share how many locales/regions you plan to support and whether you have multiple domains, I can outline a concrete URL + module structure tailored to your case.