CLI for traduora translation management
Options are set using one of the following
package.json property "traduora"
.tradourarc
.traduorarc.json
.traduorarc.yaml
.traduorarc.yml
.traduorarc.js
traduora.config.js
In combination with all-caps snake cased variants of the property names in process.env
,
prefixed with TR
. E.g TR_BASE_URL
is equivalent to base-url
in config files.
Note that the prefix itself is also configurable but it can not be set via environment variables.
CLI-Scripts are usable as npm scripts:
Example package.json scripts:
"//": "make traduora cli accessible in the project directory context -> ease of use for build steps",
"traduora": "traduora"
If you want to have your environment defined in a .env
file, you can use dotenv, too:
"traduora": "node --require 'dotenv/config' ./node_modules/.bin/traduora"
To fetch the translated terms, run
traduora --task pull
# short:
traduora -t pull
To perform remote creation for each new term found in push-from
traduora --task push
# short:
traduora -t push
Input files must be jsonflat
. Input files are matched with glob patterns. The message keys must be unique across all aggregated files.
example
{
"menu.home.button": "Home",
"messages.welcome": "Welcome {user.displayName}"
}
In order to transform the output of babel-plugin-react-intl to the desired format, consider using jq.
As an example
jq --slurp --sort-keys \
'add | reduce .[] as $item ({} ; . + {"\($item.id)": $item.defaultMessage})' \
./intl/push/**/*.json \
>| intl/push/aggregated.jsonflat
Which might be used as a preliminary step ahead of pushing the translations to traduora. Combined with dotenv
:
...
"traduora": "node --require 'dotenv/config' ./node_modules/.bin/traduora"
"preintl:push": "jq --slurp --sort-keys 'add | reduce .[] as $item ({} ; . + {\"\\($item.id)\": $item.defaultMessage})' $(find ./intl/push/* -name \"*.json\") >| build/messages/aggregated.jsonflat",
"intl:push": "npm run traduora -- -t push",
In conjunction with traduora-config
"push-from": "<rootDir>/intl/push/aggregated.jsonflat",
traduora --task translations --output ./locales.json
# short:
traduora -t translations -o ./locales.json
Obtains the locale codes which have translations. For example the resulting ./locales.json may look like
{
"de_DE": {
"region": "Germany",
"language": "German",
"id": "0ab1eed9-f98a-465a-93fd-6b3a67353164"
},
"en_GB": {
"region": "United Kingdom",
"language": "English",
"id": "544b64bb-2679-41fb-b39b-5758edbe092a"
}
}
Strings containing <rootDir>
, <locale>
or <hash:\d+>
will be interpolated. Examples:
<rootDir>
will be replaced with the absolute Path to the project root<locale>
will be replaced respective of context.<hash:6>
will be replaced with the hash of the respective file, shortened to 6 characters.
property | value | env var (default) | |
---|---|---|---|
client-id |
{String} |
client id for the client credentials flow | TR_CIENT_ID |
client-secret |
{String} |
Warning take care not to expose it in version control client key for the client credentials flow |
TR_CIENT_SECRET |
project-id |
{String} |
traduora project ID | TR_PROJECT_ID |
base-url |
{String} |
<scheme>://<host>/<basePath> – e.g. https://traduora.example.com/ |
TR_BASE_URL |
base-path |
{String} |
most likely /api/v1/ is correct |
TR_BASE_PATH |
env-prefix |
{String="TR"} |
Prefix to assume when interpolating environment variables for config options. | n/a |
locale |
{String} |
locale for authoring translation terms | n/a |
locales |
{Array<String>} |
locales to obtain from traduora | n/a |
pull-to |
{String="<rootDir>/intl/pull/<locale>.<hash:6>.json"} |
TBD | n/a |
push-from |
{GlobString,Array<GlobString}=["<rootDir>/intl/push/**/<locale>.json"] |
The interpolated Paths are serving as a pattern for globby | n/a |
pull-format |
{String="jsonflat"} |
TBD | n/a |
root-dir |
{[String]} |
Means to override <rootDir> |
TR_ROOT_DIR |
max-retry |
{Integer=5} |
Retries if API calls fail | n/a |
Until traduora-cli reaches a 1.0
release, breaking changes will be released with a new minor version. For example 0.5.1
, and 0.5.4
will have the same API, but 0.6.0
will have breaking changes.
Let your react components be the source of truth where i18n key-value pairs come to existence. Try