Translations validation with babel-plugin-ttag
One of the key features of the ttag
library is the built-in validation of the translations format.
Validation is happening when babel-plugin-ttag
is enabled in the babel configuration.
Why do we need translations validation?
- Making extracted translatable strings readable for the translator (nontechnical person).
- Having control over which strings are not translated (CI integration for example).
- Validating
ttag
functions calls with the appropriate format to prevent bugs.
Format validation
Format validation errors are enabled for all tags and functions by default.
import { t } from 'ttag';
function test(username) {
return t`${username}`;
}
Error:
ERROR in ./app.js
Module build failed: SyntaxError: Can not translate '${ username }'
1 | import { t } from 'ttag';
2 | function test(username) {
> 3 | return t`${username}`;
| ^
4 | }
This error occurred because there is no meaningful information for the translator in ${ username }
string.
More about the
t
tag format can be found in the function reference
Disabling format validation
You can disable validation by changing
extractors.[FunctionName].invalidFormat
configuration value.
Example .babelrc
file:
{
"plugins": [
["ttag",
{"extractors": { "tag-gettext": { "invalidFormat": "skip" }}}
]]
}
Missing translations
You can configure ttag to fail when some translation are not found. This setting is disabled by default.
This can be integrated somewhere on your CI workflow if you want to ensure that all strings
have appropriate translations inside .po
files prior to a deply, for example.
Enable build failure by changing resolve.unresolved
configuration value.
Example:
{
"plugins": [
["ttag",
{"translations": "uk.po", "unresolved": "fail"}
]]
}
Error:
Module build failed: SyntaxError: No "unresolved" in "uk.po" file
1 | import { ngettext, msgid, t } from 'ttag';
2 | function test(username) {
> 3 | return t`unresolved`;
| ^
4 | }