EosHQ internationalization supports a services organization that runs one delivery process across several countries while the people doing the work prefer different languages. Project names, client terms, approval rules, and billing records still need a shared meaning. The surrounding application should make that work easier to understand for each person.
EosHQ now supports English, French, German, Hindi, Italian, Korean, Portuguese, and Spanish across its application interface and transactional email. The public product website is available in the same languages. This release focuses on the language EosHQ uses for labels, instructions, status messages, navigation, and system communication. Customer-entered content remains exactly as the customer entered it.
That distinction shaped the implementation. Internationalization can look like a translation project from the outside. Inside a working product, it is also a preference, storage, formatting, routing, testing, email, and release-management project. A translated button has limited value when the next validation message appears in English or a saved preference disappears on the next device.
How EosHQ internationalization resolves language preferences
EosHQ resolves the authenticated application language in a clear order:
- User preference. A language explicitly selected in My Profile has the highest priority.
- Organization default. When the person has made no selection, EosHQ uses the organization’s chosen language.
- English fallback. English provides a dependable final value and fills any missing translation key.
The login page has less information because the person may still be anonymous. It uses an explicit selection first, then a previously saved browser choice, then the browser’s preferred language. After authentication, the server-backed user and organization settings take over.
This order gives a distributed organization a useful default while preserving individual choice. A company headquartered in Italy can make Italian the starting language. A Korean-speaking colleague can choose Korean in their profile. Each returns to the same preference on later sessions.
Keep language resources with the released application
EosHQ stores product strings in versioned static language catalogs that ship with the web application. Each catalog maps a stable source phrase to its approved translation. The browser loads the catalog for the resolved locale and applies it to labels, buttons, page titles, prompts, empty states, and other interface text.
Static catalogs fit the release model well. A code release and its language resources can be tested together. A rollback restores both. Content delivery is fast and cacheable. A temporary database issue cannot remove the words needed to explain that there is a database issue, which is a small architectural courtesy with an outsized effect during an incident.
Firestore still has a role. It stores the selected user preference, the organization default, and language registry metadata. Those values answer which language EosHQ should use. The catalogs answer what each product phrase says in that language. Separating selection from content keeps the operating model simple.
Preserve routes, permissions, and shared data
The application routes stay the same for every interface language. A Projects route remains the Projects route even when its visible title is Projekte, Progetti, 프로젝트, or Proyectos. Bookmarks, access rules, Agent processes, support instructions, and API behavior continue to refer to one stable product structure.
The same principle applies to authorization. Language selection changes presentation. It does not grant access, change a role, widen an object query, or alter an approval boundary. EosHQ resolves permissions through the same tenant and role controls before localized text is shown.
Customer-entered data also stays shared. If a team enters a project name in Portuguese and a ticket description in English, EosHQ displays those values as entered. Automatic translation could alter specialized terminology, contractual language, proper names, or a customer’s chosen wording. The release therefore localizes product chrome and system messages while preserving the organization’s own records.
Handle language generated at runtime
Some text exists only after a person takes an action. Validation messages, dynamically created dialogs, table states, and notifications all need catalog coverage. EosHQ observes new interface elements and applies the active catalog as those elements appear. Automated extraction checks JavaScript as well as HTML because many important strings live in application logic.
EosHQ Chat and Agent-generated prose follow a related path with a different mechanism. The final language-model step receives the conversation language and is instructed to answer naturally in that language. This works well when a person asks a question in Hindi and continues in Hindi. Fixed product terms around the response still come from reviewed catalogs, keeping interface terminology consistent.
Transactional emails run on the server, so their localization runs there too. The email service resolves the recipient or organization locale, selects the translated subject and body template, preserves template variables, and falls back to English when necessary. Invitations, account notices, and subscription messages can then meet the user in the same language as the product.
Give the public website stable language editions
The marketing website uses static localized URLs such as /de/, /hi/, and /es/. Each edition includes a localized title, description, canonical URL, and alternate-language links. Visitors can switch languages from the flag selector, and the browser language provides the first default when no earlier choice exists.
Static pages let search engines index each edition directly and let a person share the exact language version they are reading. Product, solution, integration, pricing, support, calculator, and company pages are included. The blog, developer documentation, and legal material remain English in this release because those bodies require a separate editorial and legal review process.
Test the fallback paths as seriously as the happy path
Internationalization testing covers more than checking whether translated words appear. EosHQ tests locale normalization, user and organization precedence, browser defaults, catalog completeness, placeholder preservation, transactional email templates, runtime-generated elements, and navigation between language editions.
Browser tests then visit the real application and public site. They switch languages, reload pages, move through routes, and capture console and network failures. Visual review matters too. German labels can be longer than English. Hindi rendering needs the correct font behavior. Korean line wrapping can reveal layout assumptions that a unit test cannot see.
English fallback remains part of the design. If a new feature adds a phrase before every translation has passed review, the person sees clear English in that one place while the rest of the interface stays in the selected language. The gap is visible to quality checks and the product remains usable.
What organizations gain
A familiar interface can shorten the distance between a process and the person expected to follow it. Labels and instructions require less interpretation. Administrators can establish a shared default. Individuals can choose the language that makes routine work easiest. Support teams can ask for a stable route and know that every user reaches the same underlying screen.
The deeper benefit is consistency. One permission model, one set of workflows, one body of customer data, and one release can serve people through several interface languages. Organizations can expand access to EosHQ without fragmenting their operating model into separate language-specific systems.
Internationalization will continue to grow as product areas and languages grow. The foundation is now part of how EosHQ extracts interface text, builds releases, sends email, tests routes, and resolves user preferences. That makes language support an ordinary product capability instead of a special project repeated for every screen.
See the internationalization product overview, or bring one of your real processes to a language-switching demo.