Uploaded image for project: 'Red Hat Internal Developer Platform'
  1. Red Hat Internal Developer Platform
  2. RHIDP-8261

Enable and document localization support to RHDH

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Done
    • Icon: Critical Critical
    • 1.8.0
    • None
    • Localization
    • None
    • Enable and document localization support to RHDH
    • M
    • False
    • Hide

      None

      Show
      None
    • False
    • RHIDP-7939Phase 1 Localization for Red Hat Developer Hub
    • In Progress
    • RHIDP-7939 - Phase 1 Localization for Red Hat Developer Hub
    • QE Needed, Docs Needed, TE Needed, Customer Facing, PX Needed
    • 0% To Do, 0% In Progress, 100% Done
    • Hide
      = Plugins localization support

      With this update, {product} integrates the {backstage} localization framework, enabling users to load translations provided by their plugins. The selected language will persist according to the user settings persistence configuration. Additionally, users can load translations from an external JSON file, allowing them to override existing translations or add translations for existing translation keys.

      == Additional resources
      * {customizing-book-link}#localization-support-for-plugins[Localization support for plugins]
      Show
      = Plugins localization support With this update, {product} integrates the {backstage} localization framework, enabling users to load translations provided by their plugins. The selected language will persist according to the user settings persistence configuration. Additionally, users can load translations from an external JSON file, allowing them to override existing translations or add translations for existing translation keys. == Additional resources * {customizing-book-link}#localization-support-for-plugins[Localization support for plugins]
    • Feature
    • Done

      1. Enable Backstage localization framework
        • First step might be to have what is available in Backstage to test and experiment early
        • But the final solution should save the changed language in the database. Maybe we can do a spike if Backstage User Settings is using a database? And we might need a custom implementation for the AppLanguageApi / AppLanguageSelector
      2. Make it possible to configure the available languages in the app-config
      3. When possible, can we have a pseudo localization feature similar to the OpenShift Console for the complete UI, incl. sidebar and plugins, to find not-yet-translated strings? Spike?
      4. Our dynamic plugin framework need to load translations from plugins (the npm plugin has translations for example, you might need export it..)
        • Translations might be part of a (dynamic plugin)
        • Additional plugins (a npm package with a language export) should be able to extend these languages
        • Question/TBD: Do we need any other solution to load translation other than packages? For example, from a JSON file?

      Acceptance Criteria

      1. The system must automatically detect and save the user's preferred language using browser settings on the first visit.
        Users must be able to override automatic detection by manually selecting from the available languages in their settings.
      2. Selected language preferences must be saved and persist across user sessions, with the UI updating instantly without requiring a page reload.
      3. The available languages can be defined in the app-config

              dsantra12 Debsmita Santra
              cjerolim Christoph Jerolimov
              RHIDP - Frontend Plugins & UI
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: