2.7 KiB
scratch-l10n
Translation of all Scratch projects is managed on the Transifex service: https://www.transifex.com/llk/public
This repository collects translations submitted to the Scratch projects on Transifex. Please do not submit PRs. If you would like to contribute translations, please sign up to translate on Transifex.
Using scratch-l10n in development
Installation
npm install --save-dev scratch-l10n
Basic Use
import locales, {localeData, isRtl} from 'scratch-l10n';
import editorMessages from 'scratch-l10n/locales/editor-messages';
locales
: currently supported locales for the Scratch projectisRtl
: function that returns true if the locale is one that is written right-to-leftlocaleData
: locale data for the supported locales, in the format accepted byaddLocaleData
required byreact-intl
editorMessages
: the actual message strings for all supported locales for a particular resource.editorMessages
collects all the strings for the interface, extensions and paint-editor.
Useful Scripts
scratch-l10n provides:
build-i18n-src
: script that uses babel and plugins to extract allFormattedMessage
strings for translation. Combines the message from all the source files into oneen.json
tx-push-src
: script to push theen.json
file to Transifex. Requires that the environment variableTX_TOKEN
is set with a value that has developer access to the Scratch projects on Transifex (i.e. Scratch Team only)
Versioning
scratch-l10n uses semantic versioning - breaking changes will increment the major version number, and new features (e.g. a new language) will increment the minor version number. However, the patch number is actually a datetime string. That way it's easy to see how recently the translations were updated.
In general, changes that require a PR (new functionality, new language) should increment the minor version. Pulling new translations from Transifex is automated and will commit to master directly.
Deprecations
We are moving away from using the tx
cli, so the .tx/config
file will eventually be deprecated.
Committing
This project uses semantic release to ensure version bumps follow semver so that projects depending on it don't break unexpectedly.
In order to automatically determine version updates, semantic release expects commit messages to follow the conventional-changelog specification.
You can use the commitizen CLI to make commits formatted in this way:
npm install -g commitizen@latest cz-conventional-changelog@latest
Now you're ready to make commits using git cz
.