DECISION: Which module should host back-end translation files?

mod-circulation returns validation and error messages that consist of a "code" (translation key), a fall-back "message" and optional parameters. We need to add about 200 translation keys for mod-circulation, see [^strings.txt] in UIREQ-603.

Other back-end modules also have validation and error messages that needs translation.

There are several front-end modules that use mod-circulation, for example ui-checkin, ui-checkout, ui-requests, and each need to get the locale specific string for the translation key.

Question: Which module should host the language files en.json, de.json, ... that contains the back-end strings for back-end translation keys?

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

Pro: Uses existing front-end modules

Con: 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.

Option 2a

For 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

Pro:

• 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.

Con: ?

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

Pro:

• 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.

Con: ?

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 frone-end modules.

Pro: 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.

Con: Is this technically feasible? How can Stripes fetch languages files from a non-Stripes module?

Option 4:

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.

Pro: Java code and translation files live in the same repository. No work for the front-end.

Con: Doesn't support translation backports: https://wiki.folio.org/display/I18N/Backport