DR-000009 - Handle i18n where messages are generated
- Radhakrishnan Gopalakrishnan
- Jenn Colt
Overrides/Supersedes
This decision was migrated from the Tech Leads Decision Log as part of a consolidation process. The original decision record can be found here.
RFC
Provide links to all relevant RFC's
Stakeholders
@mention individual(s) who has vested interest in the DR. This helps us to identify who needs to be aware of the decision
Contributors
Approvers
This decision was made by the Tech Leads group prior to the adoption of current decision making processes within the FOLIO project.
Background/Context
Multiple TC discussions, https://folio-org.atlassian.net/wiki/display/TC/2021-06-16+Meeting+Notes
Assumptions
N/A
Constraints
N/A
Rationale
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
Decision
Back-end modules should handle i18n/l10n of messages provided in responses given a locale preference received in a request, e.g. an Accept-Languages HTTP header.
Implications
- Pros
- Provide a link to RFC when applicable
- Cons
- Provide a link to RFC when applicable
Other Related Resources