I18n (Internationalization)

This document provides an overview about how we handle translations. See holi-frontends/README for example usage.

Language support and detection

• Currently we support two languages: English and German
• English is our default and fallback language
• Language selection is platform dependent:
  • Mobile: Device language using expo-localization
  • Web:
    • Locale sub-path if present (e.g. https://app.holi.social/de/spaces)
    • Request header accept-language using https://github.com/florrain/locale
• Currently the language is not part of the user profile and may vary by platform and device
  caution

  This might result e.g. in e-mails or push notifications not matching the language of the device they are received on

Technical documentation

• We use i18next as base framework as it provides a lot of options for configuration and plugins to comply to our current and possible future needs
  • Currently all translations are part of the frontend code, i.e. we do not use an external tool for editing translation yet
    • In order to allow for flexibility in tool selection, we use a commonly used format for our translations: JSON Format v3 in a flat structure (i.e. no nested keys)
    • The format allows for pluralization and variable interpolation
  • Currently all translations are part of the web and app bundles
• react-i18next for React/React Native integration
  • Provides access to translations in components with the useTranslation hook
  • Provides a Trans component for nesting components inside translations (e.g. links inside a sentence)
• ni18n for NextJS integration and SSR
• We support internationalized routing on web by using sub-paths for the locale.
  • If the URL does not contain a locale sub-path, a redirect with adding the proper sub-path with the detected locale (accept-language header of the request) is performed (e.g. https://app.holi.social/spaces → https://app.holi.social/de/spaces).
  • When deep linking on mobile, the locale sub-paths are ignored and the device language is used instead.
  • Locale specific path names are supported (e.g. https://app.holi.social/de/spenden will be internally redirected to https://app.holi.social/de/donations without changing the URL), but only used for SEO (i.e. such path names will be exposed to search engines, but not be used for navigation inside the app)
• We use namespaces to separate translations from the core application and different holi-apps
• We use Intl to provide locale data, e.g. for number or date formatting
  • On mobile this is polyfilled using intl