Spike - Investigate support for i18n in the capabilities grid

Spike Overview

JIRA ID: MODROLESKC-58 Spike - Investigate support for i18n in the capabilities grid

Objective: EUREKA needs to be able to localize capabilities and capability sets in a similar manner to OKPAI.

How OKAPI Localaize permissions Statement ?

Currently, all permissions localization is handled in the UI module and localized using the standard method with Lokalise.

Open

Deliverables

We use our application generator tools (Link) to build application descriptors, which parse module descriptors to generate them. We can extend this tool to add missing keys for capabilities into the JSON file for localization. Each time we build a new application, we generate keys from the module descriptors and compare them with the keys in the repository. If any keys are missing, we will add them for the next localization. Depending on the option chosen, the location for the capability localization files will be hosted either in the mod-roles-keycloak repo or the ui-users repo. The Maven plugin needs to be extended to include a parameter for defining the localization file location. The plugin should always update the English version located at /translations/{module-name}/en.json. Translations are moved from Lokalise to the /translations/ directories of GitHub repositories, and vice versa, by a script that Peter Murray runs every few days.

Option 1 backend module localization (mod-roles-keycloak)

The approach involves hosting the localization file in the backend module and returning the localized label to the UI. We already use similar methods for some modules, which is an established approach. Below is the documentation on how to use the folio-sprint-i18n library to handle localization on the backend.

DR-000009 - Handle i18n where messages are generated

Documentation for folio-spring-i18n features

Option 2 UI module localization (ui-users)

This approach is similar to what we currently use for OKAPI, where localization is hosted in the UI module repository. The UI module resolves translations based on the keys returned by the backend in the response.

Concerns

@Zak Burke This means a single module will manage all translations. Regardless of whether the capability translation is required for the current application, it will still contain many capability keys.

Conclusion

I would choose option 1 since we can easily manage translations on the backend for predefined capabilities and ensure the correct labels are returned for capabilities dynamically created by users.

Spike Status: Complited