npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

eslint-plugin-i18next-no-undefined-translation-keys

v3.2.1

Published

Detects translation keys in use which are missing from translation files

Downloads

20,138

Readme

eslint-plugin-i18next-no-undefined-translation-keys

Why?

A few years ago, I was working on a very large React Native project with a couple hundred engineers. In the early phase of the project, there wasn't formal governance around modularity and code-sharing - these things tend to evolve organically at first. As adjacent teams started to see value in sharing certain things with each other, it became common to move significant chunks of code into a shared module. Unfortunately, it was also common for translations to silently break in the process. Each team had their one 1 or 2 lerna modules, each with their own i18next namespace. As code got moved, there was no automated check in place that the new namespace in which it rendered had all the same keys defined.

Even today, the i18next project docs recommend a Typescript-based approach. This is fraught with caveats - you have to use TS 5, you have to enable strict mode, if your project has multiple i18next instances, then you probably can't use type-safe translations.

Frankly, the TS-based approach does not solve the problem very well. And, for those who need it most - people on big sprawling projects with multiple i18next instances - it doesn't solve the problem at all.

Instead, I went with an eslint-based approach.

What?

This plugin gives you two rules:

  • translation-key-string-literal - Asserts that translation keys should be string literals only - otherwise, we can't statically analyze them
  • no-undefined-translation-keys - Detects translation keys in your code which are missing from translation files

These are intended to be used in conjunction with:

  • i18n-json/valid-json (who doesn't love well-formed JSON?)
  • i18n-json/identical-keys (ensures that amongst all of your languages, the exact same set of keys is defined)
  • i18n-json/sorted-keys (optional, but it is nice to have your keys alphabetized)

Operational Note:

Since we know that translations for other languages aren't immediately available, the recommendation here is to put empty strings in place where you are still waiting for a translation. Then, on whatever cadence makes sense, you can run a recursive check on each file to source the empty strings and batch those together for the translators to work on.

Installation

You'll first need to install ESLint:

npm i eslint --save-dev

Next, install eslint-plugin-i18next-no-undefined-translation-keys:

npm install eslint-plugin-i18next-no-undefined-translation-keys --save-dev

Usage

Add i18next-no-undefined-translation-keys to the plugins section of your .eslintrc configuration file. You can omit the eslint-plugin- prefix:

{
    "plugins": [
        "i18next-no-undefined-translation-keys"
    ]
}

Then configure the rules you want to use under the rules section.

{
    "rules": {
        "i18next-no-undefined-translation-keys/translation-key-string-literal": "error",
        "i18next-no-undefined-translation-keys/no-undefined-translation-keys": [
            "error",
            {
                "namespaceTranslationMappingFile": "namespaceMapping.json",
                "defaultNamespace": "default"
            }
        ]
    }
}

And your namespaceMapping.json file should map your namespaces to translation file paths like so:

{
  "shared": "packages/shared/lang/en.json",
  "unitsOfMeasure": "packages/shared/lang/uom-en.json",
  "user": "packages/user/lang/en.json"
}

For those who don't use i18next namespaces (most people), you can skip defining defaultNamespace, and your namespaceMapping.json file can be as simple as this:

{
  "default": "libs/path/to/your/english.json"
}

Note: The no-undefined-translation-keys rule will ignore any non-string-literal calls to t().

Supported Rules

  • i18next-no-undefined-translation-keys/translation-key-string-literal
  • i18next-no-undefined-translation-keys/no-undefined-translation-keys