DR-000009 - Handle i18n where messages are generated

Owned by Radhakrishnan Gopalakrishnan
Last updated: May 06, 2024 by Jenn Colt
Submitted Date

 

Approved Date

 

StatusACCEPTED
ImpactMEDIUM

 

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

Zak Burke

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