Regional and Language - Article

Overview

The Regional and Language configuration establishes the platform’s localization framework.

These settings determine how the system interprets and presents information related to geography, time, and language, influencing many aspects of platform behavior including:

• Interface language and navigation labels
• System notifications and automated emails
• Storefront presentation
• Course scheduling and calendar events
• Reporting and analytics timestamps
• Tax calculations for commercial transactions

For organizations operating internationally, these settings are especially important because they ensure that the platform behaves predictably for users across different regions.

Regional configuration also helps align the learning platform with the organization’s operational context. For example, a training provider operating globally may choose one central time zone for scheduling instructor-led sessions, while a regional training provider may configure the platform according to local regulatory and tax requirements.

Because of this, regional and language settings are typically configured early during platform implementation and revisited whenever the organization expands to new markets or learner audiences.

Regional Settings

The Regional settings tab defines the platform’s default geographic configuration. These settings establish baseline assumptions used by the system when a specific configuration does not define its own regional parameters.

Administrators can configure:

These values act as system defaults and may be overridden by more specific configurations elsewhere in the platform.

Default Country

The Default country defines the geographic reference used when the system needs a country value but none has been explicitly provided.

This setting may influence:

• Default values in user profiles
• Country assumptions in commerce transactions
• Location-based rules used in automations
• Regional behavior in certain platform features

Organizations usually configure this value to match the primary operational country of the training platform.

For example:

• A Danish corporate academy may set Denmark as the default country
• A global partner academy managed from the United States may set the United States as the default country

This ensures consistent system behavior whenever country-specific logic is required.

Default Tax Location

The Default tax location is primarily used by the commerce system when calculating taxes for training purchases. When a purchase occurs, the platform attempts to determine the correct tax rules based on available data such as:

• Customer location
• Seller legal entity
• Tax configuration rules

If the system cannot determine the tax location through these inputs, it may fall back to the configured Default tax location. Organizations selling training through the storefront should configure this carefully, as it works together with:

• Tax rules
• Seller legal entities
• Payment providers

These elements collectively determine how taxes are applied across different countries and customer types.

Default Time Zone

The Default time zone defines the platform’s baseline time reference.

This setting influences how the system displays:

• Instructor-led course schedules
• Enrollment deadlines
• Automation triggers
• Activity timestamps
• Reporting data

While the platform defines a default time zone, users still experience time displays adjusted to their own environment depending on feature behavior and user profile settings.

Date And Time Formats

The Date and time tab defines how dates and timestamps appear throughout the platform interface.

Rather than controlling the actual time stored in the system, these settings determine how time and dates are presented to users across the platform. This ensures that schedules, deadlines, reports, and notifications appear in a format that matches the expectations of the organization and its learners. Administrators can configure formatting for several display scenarios. 

The examples below illustrate how the formats may appear when using a European date convention and Central European Time (CET).

These formats allow the platform to present time information appropriately depending on context. For example, compact formats are often used in lists and dashboards, while longer formats may appear in reports or detailed activity views.

Because these timestamps appear throughout the platform — including course schedules, reporting dashboards, transaction records, calendar integrations, and system emails — choosing a clear and familiar format helps users interpret dates and deadlines correctly.

Administrators often choose medium or long date formats for user-facing environments because they reduce ambiguity compared to purely numeric dates, particularly in international platforms where learners may interpret dates differently.

💡 The default time zone presentation formats have been refined through years of use across multiple industries and provide a reliable starting point that typically requires little adjustment.

Different regions commonly use different date conventions.

For example:

If the platform serves an international audience, administrators should consider which default format will be most intuitive for the majority of users.

In many global environments, organizations choose a format that reduces ambiguity, such as including the month name (e.g., 11 Mar 2026) rather than relying on purely numeric dates.

Time Zones And Display Behavior

The formatting defined in this tab works together with the Default time zone configured in the Regional settings. The system stores timestamps consistently, but the platform may display time differently depending on context, such as:

• Platform default time zone
• Course schedule settings
• User profile time zone
• Browser or system environment

For example, an instructor-led session scheduled at 10:00 CET may appear as:

• 09:00 GMT for a learner in the United Kingdom
• 04:00 EST for a learner in North America

This behavior ensures that learners see schedules relative to their own location while maintaining a consistent scheduling reference. For administrators creating events or sessions, several features also allow scheduling in alternative time zones, making it easier to coordinate global programs without manually converting time zones.

Language Configuration

The Languages tab defines which languages are available on the platform. Languages can be activated or deactivated depending on whether the platform needs to support those languages.

When a language is activated, the platform interface and system communication can be presented in that language depending on user settings.

Languages are managed through the More (⋯) menu next to each language entry. Administrators can activate languages when new learner audiences are introduced or deactivate languages that are no longer required.

Because languages affect many parts of the platform, organizations should activate them deliberately and with a clear plan for translation governance.

Default Language And Fallback Behavior

Every platform must have a default language, which acts as the system’s reference language and fallback when translations are not available.

The default language typically represents the language used for:

• Platform administration
• Original course creation
• Initial system configuration

When a translation does not exist for a specific element, the platform automatically displays the fallback language instead.

For example:

• The platform interface may appear in Spanish for a Spanish-speaking user
• System emails may be translated automatically into Spanish
• However, if a course description has not been translated, the platform will display the original English version

This fallback mechanism ensures that users always see meaningful information even when translations are incomplete.

Automated Language Translation

Supporting a large number of languages across the platform requires an approach that can scale reliably and remain consistent as the platform evolves. Eurekos therefore uses automated AI-driven translation for many system elements, allowing new features, interface updates, and system messages to be translated consistently across a broad range of languages..

This approach provides administrators with a strong starting point when operating multilingual environments, enabling the platform to immediately support a wide set of languages without requiring manual translation for every system update. Administrators can refine translations where necessary to ensure terminology, tone, and context align with their organization’s audience and industry.

Eurekos supports all of these languages through automated AI-driven translation for key system elements, including:

• Interface strings
• Standard system messages
• Email templates

These automated translations rely on the Google Cloud Translation service. The current list of supported languages can be found here: https://docs.cloud.google.com/translate/docs/languages.

At the time of writing, the system supports approximately 200 languages, though this continues to evolve as translation services expand. Automated translations provide a strong starting point for multilingual platforms. However, organizations often review and refine translations manually to ensure terminology aligns with:

• Brand voice
• Industry terminology
• Product naming conventions

This refinement can be managed through the platform’s Translations configuration (Settings → Translations).

Dialects And Regional Language Variations

While the platform supports a large number of languages, dialect variations are not automatically translated.

Examples include:

Although these dialects share a common base language, vocabulary and phrasing may differ significantly. Automated AI translations do not yet fully capture all of these subtle regional variations.

The platform can technically support these variations, but automated translation does not distinguish between them. When dialect-specific accuracy is required, organizations may choose to customize translations manually using the Translations feature. Reach out to Eurekos Service Desk, if country-specific variations are required.

Right-To-Left And Left-To-Right Language Support

The platform supports both Left-to-Right (LTR) and Right-to-Left (RTL) language directions.

Examples include:

When RTL languages are activated, the interface automatically adjusts layout and text flow to support the correct reading direction. This ensures the platform remains usable for learners regardless of writing system. 3rd party integrated services cannot be guaranteed support.

Language Strategy Considerations

While the configuration in this section primarily defines which languages are available on the platform, managing a multilingual learning environment often requires broader planning.

Organizations operating in multiple languages should consider how translations are maintained across:

• Platform interface terminology
• System notifications and automated emails
• Storefront content and course descriptions
• Learning materials and training assets

Automated translations provide a strong starting point for supporting many languages consistently. However, organizations may still review and refine translations to ensure terminology aligns with their brand, industry, and audience.

Further guidance on managing translations and multilingual environments can be found in relevant articles.