# 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](/docs/environments/overview) 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](https://www.w3.org/International/articles/language-tags/).
- **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](https://www.iana.org/time-zones).

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. Open your Environment editor and navigate to **Location & Locale**.
2. Select an existing location preset (e.g., *London*, *San Francisco*, *Sydney*) or click **Add custom preset**.
3. Enter exact decimal coordinates:
   - **Latitude**: e.g., `51.5074`
   - **Longitude**: e.g., `-0.1278`
4. Ensure **Geolocation Permission** is set to **Allow** in [Browser Permissions](/docs/environments/permissions-appearance-advanced).
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](/docs/data/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](/docs/environments/network-proxy-storage) if your application strictly enforces GeoIP redirection.