ember-intl-analyzer

Find unused translations in your Ember.js projects

Note

ember-intl-analyzer was written and is maintained by Mainmatter and contributors. We offer consulting, training, and team augmentation for Ember.js – check out our website to learn more!

Usage

npx ember-intl-analyzer

Configuration

ember-intl-analyzer can be configured by creating a config/ember-intl-analyzer.js file in your app:

export default {
  whitelist: [
    /^countries\./,
    /^currency\./,
    /^validations\.errors\./,
    /^[^.]+\.warnings\.[^.]+$/,
  ],
};

`whitelist`

If you use dynamic translations keys like this:

this.intl.t(`countries.${code}`)

then ember-intl-analyzer can not easily understand what translation keys are being used here. In that case it will ignore the dynamic translation key and show the corresponding translations as unused.

To prevent that from happening you can configure a whitelist, which accepts an array of regular expressions that will be checked when looking for unused translations.

`errorOnUnusedWhitelistEntries`

When using a whitelist to ignore dynamic translation keys, it can be easy to forget to clean up the whitelist when an entry is not used anymore. You can opt-in to make this analyzer error when this occurs, by setting the errorOnUnusedWhitelistEntries flag in the configuration file:

export default {
  errorOnUnusedWhitelistEntries: true,
};

`analyzeConcatExpression`

If your template contains translations like this:

{{t (concat "actions." (if @isEditing "save" "publish"))}}

then ember-intl-analyzer does not detect that actions.save and actions.publish are in fact used translations, so they can be incorrectly flagged as missing or unused. As the concat helper can make it harder to read, it's encouraged to rewrite it to for example:

{{if @isEditing (t "actions.save") (t "actions.publish")}}

However, if your application relies heavily on this concat helper, then rewriting may not be the best option for you. In that case, you can opt-in to analyze concat expressions too by setting the analyzeConcatExpression flag in the configuration file:

export default {
  analyzeConcatExpression: true,
};

`externalPaths`

If your application uses translations provided by (external) addons, then those translations will show up as missing by default. In order to include such translations, you can define externalPaths in the configuration file as follows:

export default {
  externalPaths: ['my-addon'],
};

This example will try to find translation files in node_modules/my-addon/translations. Patterns supported by globby are also possible here, e.g. this:

externalPaths: ['@*/*']

will look up translations in scoped addons like node_modules/@company/scoped-addon/translations.

`translationFiles`

By default, this addon will try to find missing and unused translations in any YAML or JSON file within the translations folders of your application (['**/*.json', '**/*.yaml', '**/*.yml']). However, if you would like to only analyze a subset of translation files, you can override translationFiles in the configuration file as follows:

export default {
  translationFiles: ['**/en.yaml'],
};

This example will try to find all en.yaml files in the different translations folders, but any patterns supported by globby are also possible here.

`babelParserPlugins` `extensions`

If your application uses doesn't parse correctly because it requires a specific babel plugin you can specifiy them in the config file under the key babelParserPlugins a list on plugins can be found here.

For example if you would like typescript support you can specify the typescript plugin, although please note if the plugin introduces a new file extension you will also need to specifiy that in the extensions property. See the examples below.

Typescript example

export default {
  babelParserPlugins: ['typescript'],
  extensions: ['.ts'],
};

Jsx example

export default {
  babelParserPlugins: ['jsx'],
  extensions: ['.jsx'],
};

Gts example
```js
export default {
  babelParserPlugins: ['typescript'],
  extensions: ['.gts'],
};

`--fix`

If your application has a lot of unused translations you can run the command with the --fix to remove them. Remember to double check your translations as dynamic translations need to be whitelisted or they will be removed!

`Custom t helpers`

By default this package will only check templates for ember-intl's t helper, but in some cases you may want to create a custom wrapping helper e.g. {{t-error 'error.key' error}} this helper could manage generic error situation but also accept a custom error key. If your app uses custom t helpers you can register them in you config under the helpers key.

Note: This requires the translation key to be the first parameter of the helper

export default {
  helpers: ['t-error'],
};

Caveats

There are a number of things that we do not support yet. Have a look at the Issues before using this project.

ember-intl – Internationalization addon for Ember.js

mainmatter / ember-intl-analyzer Goto Github PK