Detect possible instances of untranslated strings being used in HTML and HTML-derived template languages
i18n-lint is a tool for detecting hardcoded (untranslated) strings in HTML and template source files. It can be used a CLI utility, or as library.
i18n-lint detects instances where a HTML element's text node or certain attributes look like a hardcoded string.
See https://jwarby.github.io/i18n-lint/ for the full documentation and demos.
Install using npm:
$ npm install -g jwarby/i18n-lintInstalling globally will give you access to the i18n-lint binary from anywhere.
See https://jwarby.github.io/i18n-lint/ for the full documentation.
The CLI program is called i18n-lint, and will be available once i18n-lint has been installed globally.
Usage:
$ i18n-lint [OPTIONS] <file ...>- Run
i18n-lint --helpori18n-lint -hto display help output and then exit - Run
i18n-lint --versionori18n-lint -Vto display version and then exit - Run
man i18n-linton systems which supportmanto view the Linux manual page
To lint a file, call i18n-lint <file>:
$ i18n-lint some_file.htmlYou can use a glob pattern too:
$ i18n-lint app/views/**/*.htmlDisplay help and then exit
Display version information and then exit
Set the template delimiters which the source files use. The value should be the start and
end delimiters, separated by a comma. For example, if running
i18n-lint against template files which use a Mustache-like syntax, use the following:
$ i18n-lint -t "{{,}}" views/**/*.hbsSimilarly, but for EJS-syntax:
$ i18n-lint -t "<%,%>" views/**/*.ejsA comma-separated list of which HTML attributes should be checked.
A comma-separated list of HTML tags to ignore when searching for hardcoded strings.
The reporter to use when outputting information. The reporters follow the same structure as
JSHint reporters, and the i18n-lint library reports error in the same manner as JSHint - this
means you can use any existing JSHint reporters as reporters for i18n-lint!
There are 3 built-in reporters that get shipped with i18n-lint: default, unix and json.
To write your own reporters, look to lib/reporters/*.js as a starting point.
A comma-separated list of file patterns to exclude, such as 'docs/,ignored.html'.
Maintain/turn off colored output. For more info, see https://www.npmjs.com/package/chalk#chalk-supportscolor.
0: if everything went OK, and no hardcoded strings were found1: if hardcoded strings were found64: command-line usage error, e.g. no input files provided ([EX_USAGE])66: cannot open input, e.g. input files I/O error, specified reporter file does not exist ([EX_NOINPUT])70: internal software error ([EX_SOFTWARE])
To maintain colored output, run i18n-lint with the --color flag:
$ i18n-lint --color **/*.html | less -RTo use i18n-lint as a library, install it locally and require it in your projects:
$ npm install --save-dev i18n-lintvar I18nLint = require('i18n-lint');
var errors = I18nLint('some_file.ejs', {
templateDelimiters: [['<%','%>']],
attributes: ['title', 'alt', 'data-custom-attr']
});Note: prior to v1.1.0, only a single set of template delimiters could be passed. However, the legacy single-depth API is still supported, ie:
templateDelimiters: ['<%', '%>']will still work (but is not recommended).
If you want to scan a string instead of reading in a file, you can use the scan function:
var I18nLint = require('i18n-lint');
var context = '<h1>Some hardcoded string</h1>\n<br>\n<p>\ncontent not translated</p>';
var options = {
// ...snip...
};
var errors = I18nLint.scan(context, options);The scan function can also accept a fileName parameter:
var I18nLint = require('i18n-lint');
var stdin = '';
// Read stdin stream
// ...snip...
// Once stdin has finished...
var errors = I18nLint(context, options, 'stdin');This allows more meaningful output when the reporters print a filename.
Options are passed as an object, as the second parameter to i18n-lint.
Specify the start and end template delimiters which the source files use. We can specify multiple delimiters if needed. For example, when linting EJS files:
I18nLint('file.ejs', {
templateDelimiters: [['<%', '%>']]
});Specify which HTML attributes to check when searching for hardcoded strings.
An array of tags which should be ignored when searching for hardcoded strings.
When using i18n-lint as a library, you can still use the reporters:
console.log(I18nLint.reporters);
// {
// default: [Function]
// }
var reporter = I18nLint.reporters.default;
var errors = I18nLint('file.html', {});
reporter(errors);There are currently 3 built-in reporters: default, unix and json.
To use other reporters, simply require them:
var I18nLint = require('i18n-lint');
var reporter = require('i18n-lint-awesome-reporter');
reporter(I18nLint('file.html', {}));{
file: '', // string, file which contains the errors,
error: {
id: String, // usually '(error)'
code: String, // warning code (see Warning Numbers)
reason: String, // message describing the error
evidence: RegExp, // with the offending text in match groups
line: Number, // line number of the error
character: Number, // column where evidence begins
scope: String // where the error was found
}
}There is a grunt task which wraps i18n-lint's functionality, which
can be found at https://github.com/jwarby/grunt-i18n-lint.
W001: hardcoded text node foundW002: hardcoded attribute value found
See CONTRIBUTING.md.
npm test- lints JS files in
bin/,lib/andtest/ - runs
mochatest suite
- lints JS files in
npm run-script coverage- coverage is output to a
./coveragedirectory
- coverage is output to a
i18n-lint follows SemVer rules for version numbers.
23rd Aug 2020
- Support for more than one set of template delimiters add - thanks @alexmorvan
18th Sep 2019
First published release.
Copyright (c) 2015 James Warwood. Licensed under the MIT license.
See AUTHORS.txt.
- CLI app scaffolding from https://github.com/Hypercubed/generator-commander