I18n (Internationalization)

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

Note that localizaton is managed in Localazy which serves as source of truth for copies and translations.

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 and configured it to optimize integration with Localazy. This means:
  • Localazy is the source of truth for translations. The frontend code only holds a snapshot of these, which gets updated nightly on the main branch.
  • The translation snapshots are part of the web and app bundles
  • Translations can be updated manually using yarn i18n:download
  • If it should be necessary to upload translations from the frontend code, the script yarn i18n:upload can be used
  • We use JSON Format v4 for the translation files with support for pluralization and variable interpolation. Currently we did not enable support for nested keys or arrays.
• 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 Intl to provide locale data, e.g. for number or date formatting
  • On mobile this is polyfilled using intl