Background
Multiple TC discussions, https://wiki.folio.org/display/TC/2021-06-16+Meeting+Notes
Following options were considered. All options except Option 4 involves stripes in some manner.
Coupling the API backend to a specific front end framework limits the usage of FOLIO API to only clients that are built using Stripes. As a result, Option 4 was chosen.
Option 1 Distribute them over the existing front-end modules
ui-checkin with translation key ui-checkin.mod-circulation.itemNotFound
ui-requests with translation key ui-requests.mod-circulation.patronHasItemOnLoad
Pros
- Uses existing front-end modules
Cons
- Cannot disable a front-end module for a tenant if it hosts a mod-circulation translation key that is needed by another enabled front-end module.
- Not all originating messages can be mapped to a frontend module
Option 2a or each back-end module with translation keys create a dedicated front-end module with language files
For example create ui-mod-circulation module, and use translation keys
ui-mod-circulation.itemNotFound
ui-mod-circulation.patronHasItemOnLoad
Pros
- Any front-end module that uses mod-circulation can require ui-mod-circulation to load the translation files.
- All mod-circulation translation strings go into a single module.
Cons
- Additional overhead in managing more ui modules
- Not all originating messages can be mapped to a frontend module
Option 2b For each back-end interface with translation keys create a dedicated front-end module with language files
For example create i18n-circulation module, and use translation keys
i18n-circulation.itemNotFound
i18n-circulation.patronHasItemOnLoad
Pros
- Any front-end module that uses the circulation API can require i18n-circulation to load the translation files.
- All circulation translation strings go into a single module.
Cons
- Additional overhead in managing more ui modules
- Not all originating messages can be mapped to a frontend module
Option 3 The back-end module hosts the language files.
mod-circulation creates a translations/mod-circulation/ directory.
Stripes fetches the translation files from the back-end module and can process them the same way as translation files from front-end modules.
Pros
- Software and language files are in the same repository. Options 1 and 2 require to add the message string to some other repository using a second pull request.
Cons
- Is this technically feasible? How can Stripes fetch languages files from a non-Stripes module?
Option 4: Back-end module does all translation work.
When calling the back-end pass the required locale. The back-end maintains the translations files, replaces the placeholders and puts the final string into the "message" property. A lang query parameter that many FOLIO API interfaces already have or an "accept-language" header line might be used.
Pros
- Java code and translation files live in the same repository. No work for the front-end.
- This is a well known pattern in the Java community
Cons
- None