Uploaded image for project: 'Stripes'
  1. Stripes
  2. STRIPES-750

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

    XMLWordPrintable

    Details

    • Type: Story
    • Status: Closed (View Workflow)
    • Priority: P3
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
    • Template:
    • Development Team:
      Stripes Force

      Description

      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

       

        TestRail: Results

          Attachments

            Issue Links

              Activity

                People

                Assignee:
                Unassigned Unassigned
                Reporter:
                julianladisch Julian Ladisch
                Votes:
                0 Vote for this issue
                Watchers:
                4 Start watching this issue

                  Dates

                  Created:
                  Updated:
                  Resolved:

                    TestRail: Runs

                      TestRail: Cases