Add translation support for UI components based on browser locale

[latin-panda]

Description

Currently, UI components such as buttons, labels, and other text elements (e.g., the PrimeVue Calendar component) do not adapt to the user’s browser language. To improve internationalization (i18n), these components should display text in the language corresponding to the browser’s locale (e.g., navigator.language). This will enhance the user experience by providing a localized interface without requiring manual language selection.

User Story

As a user,
I want all UI elements on the screen (e.g., buttons, labels, calendar labels) to automatically display in my native language based on my browser’s locale,
So that I can interact with the application in a familiar and comfortable way without needing to manually set my language preference.

Considerations

• How should UI language interact with form language (see forum thread about Enketo behavior)
• PrimeVue has a configuration to define the language as json. There is a project already providing translations to many languages, but it seems heavy (1MB unpacked)
  • We can take some of these translations to keep the bundle light.
  • Ideally only the required language is requested
• Not all components are PrimeVue, and they still need translations (Geopoint). Search by TODO: translations to find places where translations are needed.
• The browser’s locale is determined using navigator.language (e.g., "en-US" → "en").
• Only static UI text (e.g., button labels, calendar labels) needs translation at this stage; dynamic content is translated in the form definition.
• A fallback language (English) is acceptable when the user’s locale is unsupported.
• Transifex to match other ODK tools
• Bootstrap with Collect/Central/Enketo strings?
  • Enketo
  • Collect
  • Central
• Define strings in a single giant file like Collect/Enketo or have option to define by component like with Central?

Tasks

• Design: Design a uniform solution for all components (PrimeVue and non-PrimeVue components)
• Define Translations: Define languages and create a translation object/map covering buttons, labels, etc.
• Test: Create a test plan. Verify the UI updates correctly when switching browser languages (e.g., English → Spanish → French).
  • ticket: add e2e tests for translations
• Implementation: Add logic to detect the browser’s language using navigator.language and map it to supported locales. Ensure buttons, labels, and other UI elements use the detected locale’s translations.
• Documentation: Update the project’s README or developer guide with instructions on adding new languages.

Related

• Dates are always displayed and entered in mm/dd/yyyy format regardless of locale #393
• Time Input Display (12h vs 24h) #670

[lognaturel]

We may want to consider something like the host application managing and serving translations as requested. For example, if my browser locale is XYZ, the host application would be responsible for providing translations just for locale XYZ to WF and might request it from a backend.