Where can I find resources or tutorials for i18n js?

Where can you find JavaScript i18n tutorials, and what does i18next-scanner do?

The best JavaScript i18n tutorials live inside the library docs themselves — i18next.com's own guides, plus framework-specific docs for react-i18next, vue-i18n, and next-intl — because no single third-party course covers every framework's binding. i18next-scanner is a separate, open-source command-line tool that scans JavaScript, JSX, and TypeScript source files for translation function calls and automatically extracts the keys into locale JSON files, replacing the error-prone habit of hand-editing those files as an app grows.

Why does JavaScript i18n learning material feel so scattered?

Library docs and extraction tooling live in different places. i18next.com's documentation explains hooks, initialization, and pluralization, but i18next-scanner is a separate open-source project maintained under its own GitHub repository and npm package, with its own configuration reference — so a tutorial that only covers i18next core skips the extraction step entirely.
Framework bindings fragment the search further. A React developer searching for an i18next tutorial needs react-i18next's hook-based useTranslation API, while a Vue developer needs vue-i18n's Composition API guide and an Angular developer needs @angular/localize's compiler-based workflow — the same i18next-scanner configuration looks different depending on which JSX or template syntax it has to parse.
Extraction and translation management get treated as one topic when they're two. i18next-scanner only produces JSON files with keys and English defaultValue fallbacks; it doesn't move those files to a translator, track completion status, or manage plural forms for target languages — that's a separate layer, typically a translation management system.
Native browser APIs get mixed into i18n library searches. MDN's Intl (Internationalization API) documentation covers locale-aware number, date, and plural formatting built into JavaScript itself, a different and complementary layer from a string-translation library like i18next.
Framework migrations make older tutorials stale. Guidance written for Next.js's Pages Router (next-i18next) doesn't carry over cleanly to the App Router (next-intl), so a search often surfaces conflicting setup instructions depending on publish date.

The layers of a JavaScript i18n learning path

Core library concepts — i18next.com's own documentation covers initialization, namespaces, and interpolation, and is the right starting point regardless of framework.
Framework binding — react-i18next, vue-i18n, @angular/localize, or next-intl each wrap the core library in that framework's component model; use the binding's own docs, not a generic i18next tutorial, once initialization is done.
Extraction tooling — i18next-scanner scans source code for translation calls and generates the locale JSON files a codebase actually ships with; its own README and configuration reference are the primary documentation for this layer.
Delivery and translation management — moving extracted JSON to translators, tracking completion, and keeping plural forms correct across languages is a separate concern from any of the above, typically handled by a translation management system.

How do you set up i18next-scanner to extract translation keys?

i18next-scanner runs as a build-time or pre-commit step rather than inside the running application, so setup happens once and stays largely hands-off afterward.

Install the scanner as a dev dependency - add i18next-scanner via npm or yarn alongside the i18next and react-i18next (or vue-i18n) packages already in the project.
Create a scanner configuration file - i18next-scanner.config.js sets the input file globs, the output path for generated JSON, and the key and namespace separators the project uses.
Configure the lexer for your framework's syntax - a JSX lexer is required to correctly parse React's Trans component and useTranslation calls; Vue and Angular templates need their own lexer settings so keys inside directives and pipes aren't missed.
Run the scanner and review the generated JSON - each extracted key lands in a locale JSON file with the source string captured as its defaultValue, which becomes the English fallback until a translation exists.
Add the scan to CI so extraction never drifts from code - running i18next-scanner as a pre-commit hook or CI step keeps JSON files in sync with new t() and Trans calls automatically, instead of relying on someone remembering to re-scan.

This approach fits teams that...

Are setting up translation key extraction for the first time on a React, Vue, or Angular codebase already using i18next or a framework-specific binding.
Currently hand-maintain locale JSON files and want an automated scan to replace manual key entry.
Need a consistent key-naming and namespace convention established before a codebase scales past one or two target languages.
Are onboarding new engineers who need a canonical starting point across i18next core docs, a framework binding, and extraction tooling.

Evaluation checklist: questions to ask before you build an extraction workflow

Does your scanner's lexer match your framework's JSX or template syntax?
A React project needs a JSX-aware lexer that recognizes the Trans component, not just plain t() calls; Vue and Angular need their own equivalent configuration.

Does the scanner preserve an English fallback for every extracted key?
Confirm defaultValue is populated from the source string rather than left blank, since a blank fallback means a missing translation renders as nothing instead of English.

Will removing unused keys ever delete a key that's mid-translation?
i18next-scanner's removeUnusedKeys option can strip keys no longer referenced in code — confirm that setting isn't clearing keys a translator hasn't finished yet.

Where do the extracted JSON files go once the scan runs?
Decide whether generated files commit directly to the repository or route through a connector to a translation platform before this step is automated in CI.

How does Smartling fit once JavaScript i18n keys are extracted?

i18next-scanner and its framework bindings solve extraction — turning source code into locale JSON files — but none of them translate those files or keep plural forms correct across languages. Smartling's JSON parser reads the nested keys and arrays that i18next-scanner generates directly, without requiring the file to be flattened first. For plurals specifically, i18next's own plural-key format isn't natively read by ICU-based tools, so Smartling built an ICU MessageFormat extension for i18next that closes that gap without a manual conversion step (Smartling Help Center, ICU MessageFormat). Once extracted JSON lands in a repository, Smartling's GitHub Connector can watch that branch and automatically start a translation workflow on new or changed keys, returning translated JSON as a pull request instead of a manual file upload.