langs

ISO 639-1/2/3 language codes with English and local names for Node.js

Library
npm
v2.0.0
121stars
MIT License

Repository Health

Pre-computed score based on development activity, maintenance, community, maturity, and trend momentum.How we score it →
29/100Needs Attention
Development Activity0
Maintenance0
Community44
Maturity60
Momentum12

Technical Analysis

AI-assessed by reading the actual repository — architecture, code quality, innovation, and documentation.How we score it →
52/100Fair
Architecture63
Code Quality52
Innovation57
Learning Curve35

langs is a small, dependency-free npm library that ships the full ISO 639-1/2/3 language code standard as a plain JavaScript dataset, paired with a handful of lookup helpers. Instead of hand-rolling a table of language codes and names, applications can require langs and immediately query it for a language’s English name, local name, or any of its four ISO code variants (639-1, 639-2/T, 639-2/B, 639-3).

The library exposes five functions — all(), has(), codes(), names(), and where() — that cover the common access patterns for this kind of reference data: dumping the whole list, filtering by a code type, and finding or checking for a specific language by any known field. It’s a good fit anywhere a Node.js app needs to validate, translate, or display ISO language codes without pulling in a heavier internationalization framework.

What You Get

  • A complete ISO 639-1/2/3 dataset bundled as a plain JS array (data.js), so lookups work fully offline with no network calls
  • Five focused query functions — all(), has(), codes(), names(), and where() — covering listing, existence checks, code extraction, and record lookup
  • Support for all four ISO 639 code variants per language (1, 2/T, 2B, 3), including the macrolanguage distinctions (e.g. Arabic ‘ara’ vs Standard Arabic ‘arb’)
  • Zero runtime dependencies — the entire library is a single require()‘d module with no transitive install weight
  • A Mocha/Chai test suite (test.js) exercising the public API against known language records for regression safety

Common Use Cases

  • Validating a user-supplied or API-supplied language code against the real ISO 639 standard before storing or acting on it
  • Populating a language picker or dropdown with proper English and local-language names instead of raw codes
  • Converting between ISO 639 code variants (e.g. 2-letter to 3-letter) when integrating with APIs that expect a specific variant
  • Displaying a language’s native/local name alongside its English name in localized UI

Under The Hood

Architecture langs is a single flat module: index.js defines the entire public API (all, has, codes, names, where) as thin wrappers around one in-memory array exported from data.js, plus two private helpers (forAll, isValidType, findBy). Every exported function indexes directly into the same record shape (name, local, 1, 2, 2T, 2B, 3), so there’s no internal layering to trace — a change to the record shape would touch every function at once, but the surface area is small enough that this trade-off is reasonable for the library’s scope.

Tech Stack The library is plain ES5 JavaScript with zero runtime dependencies — no build step, no transpiler, no bundler. It’s tested with Mocha (TDD-style suites) and Chai assertions, declared as devDependencies, and wired to a legacy Travis CI config. It ships as a CommonJS module consumed via a single require(‘langs’) call, published directly to npm with no compiled output.

Code Quality test.js exercises the public API extensively against known language records (English, Korean) across every ISO 639 variant, using clear TDD-style suite/test blocks. Functions favor silent undefined returns over thrown errors for invalid input (e.g. an unrecognized code type or unmatched lookup), which keeps the API forgiving but offers no explicit error signaling. There’s no TypeScript, no linter configuration, and no modern CI beyond the legacy Travis file, though naming is consistent and functions carry lightweight Hindley-Milner-style type comments for documentation.

API Design The five-function surface (all/has/codes/names/where) maps cleanly onto the common access patterns for reference data — list everything, check existence, extract one code type, list names, or find one record — so a new consumer can get productive from the README’s inline examples alone. Getting started requires nothing beyond a single require() call, with no configuration or setup. The value here is the curated ISO 639 dataset plus this convenience layer, rather than any structural novelty in the API itself.

Join founders buildingwith open source

Opinionated takes, migration guides, cost-saving tips, and insights from the open source ecosystem.

Subscribe on Substack
Join 750+ subscribers

Search