Test with a Different Location or Locale

Modern web applications adapt dynamically based on where users connect from and what language they speak. The Location & Locale settings in the Environments editor allow you to simulate any geographical coordinate, language preference, and regional formatting standard.

Locale and internationalization standards

TestOwl adheres strictly to international web standards for language and regional formatting:

• BCP 47 Language Tags: Language preferences are specified using standard language and region codes (e.g., en-US, en-GB, fr-FR, de-DE, ja-JP). Refer to the official W3C BCP 47 Language Tags Specification.
• IANA Time Zone Database: Timezones are configured using standard timezone identifiers (e.g., America/New_York, Europe/London, Asia/Tokyo). Refer to the official IANA Time Zone Database.

When you specify a locale, TestOwl sets the browser's navigator.language, Accept-Language HTTP request headers, and localized JavaScript Intl APIs automatically.

Worked examples: Testing regional differences

Example 1: Currency symbols and number separators

An e-commerce checkout page that displays product totals must format currency according to regional conventions:

• US Locale (en-US): Formats $1,250.99 with commas for thousands and a period for decimals.
• German Locale (de-DE): Formats 1.250,99 € with periods for thousands and a comma for decimals.
• UK Locale (en-GB): Formats £1,250.99.

In TestOwl, create separate environments for US Storefront and EU Storefront. Your test assertions can verify that the expected currency symbol and punctuation render for each market.

Example 2: Date formatting in form inputs

Date pickers and booking confirmations change order depending on geography:

• United States (en-US): Month / Day / Year (10/24/2026).
• United Kingdom (en-GB): Day / Month / Year (24/10/2026).
• ISO Standard (sv-SE / ja-JP): Year - Month - Day (2026-10-24).

Testing with locale-specific environments ensures that date validation scripts do not reject valid European dates as invalid months (e.g., treating October 24th as month 24).

Example 3: Right-to-Left (RTL) language layouts

For languages such as Arabic (r-SA) or Hebrew (he-IL), web browsers flip navigation menus, icons, and text alignment from left-to-right to right-to-left. By validating your user flows in an RTL locale environment, TestOwl captures automated screenshot comparisons to verify that flexbox columns, button order, and chevron orientations invert correctly without causing layout overflow.

Simulating geolocation coordinates

Applications offering store locators, localized delivery estimates, or regional access rules require geolocation permissions and GPS coordinates:

1. 1
   Open your Environment editor and navigate to Location & Locale.
2. 2
   Select an existing location preset (e.g., London, San Francisco, Sydney) or click Add custom preset.
3. 3
   Enter exact decimal coordinates:
   • Latitude: e.g., 51.5074
   • Longitude: e.g., -0.1278
4. 4
   Ensure Geolocation Permission is set to Allow in Browser Permissions.
5. 5
   When your web application queries navigator.geolocation.getCurrentPosition(), TestOwl immediately returns the configured simulated coordinates without prompting.

How locale interacts with test assertions

When writing test assertions that verify text on page, localized environments require thoughtful assertion strategies:

• Avoid Hardcoding Localized Strings in Shared Flows: If a flow checks for the exact button text "Submit Order", running that flow in a French environment will fail when the button displays "Passer la commande".
• Use Dynamic Variables for Localized Expectations: Store expected labels in environment-scoped Variables (e.g., {{var.submit_button_label}}), allowing each environment to supply its own expected translation.
• Assert on Semantic Attributes: Whenever possible, assert on invariant attributes such as data-testid="submit-order" or input IDs rather than localized inner text.

Common problems with localized testing

• Timezone Shifts Affecting Date Pickers: If a test runs on an environment configured for Tokyo (UTC+9) while your cloud runner server operates in UTC, a date picker defaulted to "Today" might select tomorrow's date. Always align both the Timezone and Locale in your environment settings.
• Language Detection from IP Addresses: Some websites ignore browser Accept-Language headers and determine country strictly via GeoIP lookup. Because cloud runners connect from data center IP ranges, use a dedicated regional Proxy if your application strictly enforces GeoIP redirection.