Table of Contents
...
Translation is done by human translators.
- If you are willing to help with string translations, join the translation team and contact Peter Murray, he will set you up on lokalise.com.
- To begin work on translations for a new language or region, contact Peter Murray.
Currently all translators must use the web tool Lokalise (https://lokalise.com/) that shows the English text and a text field for the translation. Lokalise gives advice when the text contains placeholders and offers machine translations as suggestions.
- Do you want to use a different online or offline computer aided translation tool (CAT)? Contact Peter Murray to setup downloading and uploading XLIFF files.
- You are a developer? Read Explain internationalization and localization.
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 eachstripes-*,
ui-*,
andmod-*
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 inprotected-translation-keys.json
explains the reason, for example "dynamically created" or "TODO: check whether this key is still in use, remove if not".
...
Only translate the text within the second level curly braces. Do not translate the key words on the first level curly braces ("count, plural, one") and do not translate the key word words on the third level curly braces ("count, number"). The category key words zero
, one
, two
, few
, many
, other
within the first level curly braces must be kept untranslated, see Unicode list of languages and category key words.
...