Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

...

Translation deployment

  • Translations are moved from Lokalise to the /translations/ directories of GitHub repositories by a script that Peter Murray runs every few days. They show up as a pull request on each stripes-*, ui-*, and mod-* repository as applicable, are run through the CI tests, and automatically merged. CI tests don't always pass and may require manual restart.
  • This is a one-way process. Any manual change to locale files on GitHub will be overwritten and are lost when new locale files from Lokalise come in.
  • https://folio-snapshot.dev.folio.org/ is the first reference environment where new or changed translations appear because it uses the master branch. Other reference environments take longer because they only use released front-end module versions, see Reference Environments for details.
  • Any FOLIO release like Honeysuckle, Iris, etc. ships with the translations that come with each front-end module. Each front-end module has a different release date (Honeysuckle example). This is the time when translations are taken from module's GitHub translations directory and is different for each front-end module. A new front-end module release is needed to get more recent translation included into a FOLIO release.
  • However, the sysOp of a FOLIO installation may manually update the translations of their installation by exchanging the files in the /translations/ directory from where the static files are shipped. See Backport how to do it.

  • Translation keys deleted from en.json still exist on lokalise.com for older FOLIO releases. Example: A translation key is no longer in use in Iris release, but translators are still working on the Honeysuckle release where it is use.

    • TODO: Write a script that removes translation keys on lokalise.com after a grace period. Old translations will remain in the GitHub history (example). Proposal for grace period: 4 months, matching the release cycle.
    • TODO: Write a script that searches for translation keys deleted from en.json and add a comment on lokalise.com stating the last FOLIO release it is in use.
    • TODO: Write a script that checks that all translation keys in en.json are still in use in that ui module and fail a pull request if not. An exemption file, for example /translations/protected-translation-keys.json, lists translations keys that should not fail the pull request, this is for translation keys that are dynamically concatenated at run-time, that are used by other modules, or that fail at the time when the script is installed and need to be checked at a later time. The value in protected-translation-keys.json explains the reason, for example "dynamically created" or "TODO: check whether this key is still in use, remove if not".

...

The error may break the build pipeline for the UI module.

For advanced users: If the build pipeline for the UI module breaks fork the repository and enable the build-npm.yml GitHub Action workflow in your fork. Manually fix the problem in the .json files of your fork. This should trigger the build-npm.yml workflow. Repeat until the "Run yarn formatjs-compile" step succeeds. Then extract the changed string with a jq query like this (to remove the \ masking) and paste it into Lokalise: jq -r '."harvestables.field.csvConfiguration.help"' < de.json

Language rules

See Language rules in "MOTIF: The FOLIO design system" for the user experience (UX) recommendations and guidelines for the language of text in FOLIO's user interface.

...