scratchfoundationscratch-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
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 byaddLocaleDatarequired byreact-intleditorMessages: the actual message strings for all supported locales for a particular resource.editorMessagescollects 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 allFormattedMessagestrings for translation. Combines the message from all the source files into oneen.jsontx-push-src: script to push theen.jsonfile to Transifex. Requires that the environment variableTX_TOKENis 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. Pulling new translations from Transifex is automated
and will increase the patch version.
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.
Here's a quick introduction:
- Prefix your commit subject with
fix:if it fixes a bug but doesn't add any new functionality and doesn't change the API. - Prefix your commit subject with
feat:if it adds new functionality but maintains backwards compatibility. - Include
BREAKING CHANGE:as a footer in your commit body, or add!to the commit subject, if the change breaks compatibility with existing code. - Other prefixes, such as
chore:,docs:, etc., are allowed but will not change the version or cause a new release. These should only be used for changes that do not affect functionality.
Example commit messages
For more examples, see the conventional commits documentation.
Fix
This will increase the z in Version x.y.z.
fix: fix typo in the sandwich-making instructions
Feature
This will increase the y in Version x.y.z and reset z to 0.
feat: add support for halloumi cheese
Breaking Change
Either of these will increase the x in Version x.y.z and reset y and z to 0.
fix: refine our definition of a sandwich
BREAKING CHANGE: support for hot dogs has been removed as we no longer consider them sandwiches
fix!: remove support for hot dogs as we no longer consider them sandwiches
Commitizen
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.