transliteration

Converts Unicode text from any writing system into Latin ASCII or URL-safe slugs, with zero runtime dependencies.

Library
npm
v2.6.1
642 stars
MIT License

Repository Health

Pre-computed score based on development activity, maintenance, community, maturity, and trend momentum. How we score it →
39 /100 Needs Attention
Development Activity 0
Maintenance 20
Community 56
Maturity 60
Momentum 20

Technical Analysis

AI-assessed by reading the actual repository — architecture, code quality, innovation, and documentation. How we score it →
75 /100 Good
Architecture 78
Code Quality 86
Innovation 82
Learning Curve 55

transliteration is a JavaScript/TypeScript library exposing two functions, transliterate() and slugify(), that convert Unicode strings (Chinese, Korean, Greek, Cyrillic, and other scripts) into their closest Latin/ASCII equivalents using a large embedded character map. It ships a full build covering the whole map (~186 KB) alongside a separate, much smaller transliteration/latin entry point (~5 KB) restricted to Basic Latin and Latin Extended ranges, so consumers who only need Western-European coverage can opt out of the larger CJK/Korean data. The package runs identically across Node.js, browsers, Web Workers, React Native, and Electron, ships bundled TypeScript type definitions, and has no runtime dependencies at all.

Beyond the core API, transliterate() and slugify() both expose config() and setData() methods for setting persistent global defaults or overriding parts of the character map, plus per-call options for custom replace/ignore string handling, Chinese-specific spacing fixes, and slug casing/separator control. Two CLI binaries, transliterate and slugify, wrap the same logic for shell scripting and stdin piping use cases.

What You Get

  • transliterate() and slugify() functions - core API for Unicode-to-Latin conversion and URL-safe slug generation
  • Latin-only build variant - the transliteration/latin sub-path ships a ~5 KB bundle instead of ~186 KB by dropping CJK/Korean/etc. charmap data
  • Bundled TypeScript types - full .d.ts definitions ship in dist, no separate @types/transliteration package needed
  • CLI binaries - transliterate and slugify commands for shell scripting and stdin piping
  • Cross-platform builds - separate CJS (Node), ESM, and UMD bundles cover browser, Web Worker, React Native, and Electron usage

Common Use Cases

  • Generating SEO-friendly URL slugs - convert post titles or user-generated names in any language into ASCII slugs for routes
  • Normalizing multilingual user input - transliterate names or addresses from CJK, Cyrillic, Greek, or Korean into a Latin-searchable form
  • Filename sanitization - strip Unicode from user-uploaded filenames while keeping them readable
  • Command-line text conversion - call the CLI from build scripts or shell pipelines to romanize text files

Under The Hood

Architecture The library is organized as a layered common/platform split: src/common holds platform-agnostic core classes (Transliterate in transliterate.ts, Slugify extends Transliterate in slugify.ts, plus shared regex/range helpers in utils.ts), while src/node, src/browser, and src/cli each compose those primitives into a distinct entry point - src/node/index.ts and src/browser/index.ts bind Transliterate/Slugify instances into plain function exports with attached .config/.setData methods, and src/cli wraps the same classes with a hand-rolled, zero-dependency argument parser in cli/common.ts. transliterate() runs a four-stage pipeline (pre-replace, charmap walk with surrogate-pair-aware iteration in codeMapReplace, optional trim, post-replace), and slugify() calls transliterate() then pipes the result through an allowedChars strip and separator collapse. The charmap itself (generated by scripts/generate-data.ts) is treated as immutable unless explicitly overridden via setData(), so the Transliterate class constructor is the single real coupling point shared by every downstream entry point.

Tech Stack Written in TypeScript targeting ES2020, built with tsup (esbuild-based) into four separate output profiles - node CJS with .d.ts, browser ESM, browser UMD (global name transliteration), and CLI binaries with a shebang banner - and published with zero runtime dependencies. The dev toolchain uses Bun as both package manager and script runner, Vitest with v8 coverage and happy-dom for browser-environment tests, and Biome (via the ultracite preset) for combined linting and formatting in place of a traditional ESLint+Prettier pair. CI runs lint, build, and coverage-tracked tests on every push/PR via GitHub Actions, uploading results to Codecov, with a second workflow auto-publishing to npm once a build succeeds against an untagged version.

Code Quality Every core module has a co-located test file (transliterate, slugify, utils, latin, cli, and browser index all have matching *.test.ts files), run through Vitest with coverage enforced in CI. The sampled source shows explicit typed function signatures throughout, narrow exported types, and deliberate defensive choices - an iterative binary search replacing recursion in inRange for performance, and a documented ReDoS-safe fallback regex in the custom replace path. Complexity-suppression comments are annotated with a stated reason rather than silently disabled, and coverage-ignore markers call out intentionally untested defensive branches. No error-swallowing patterns were observed in the sampled files, and the strict Biome preset gates merges in CI.

API Design The public surface is deliberately small: two exported functions, transliterate() and slugify(), each taking a string plus an optional options object, with .config()/.setData() attached for global customization so consumers never need to instantiate the underlying classes directly. Zero configuration is required to get useful output, while a documented options table (ignore, replace, replaceAfter, trim, unknown, separator, allowedChars, fixChineseSpacing) covers the edge cases the README’s own Known Issues table calls out. Option naming is consistent between transliterate and slugify, the CLI mirrors the same flag semantics as the JS options, and bundled TypeScript types give consumers autocomplete without an extra @types install.

Used by 5 apps in this directory

TypeScript
64%
Other

Epicenter

Developer Tools · Knowledge Management · Note Taking

4,808

A local-first monorepo led by Whispering, an open-source speech-to-text app, built on an MIT toolkit that turns your data into plain Markdown and SQLite files you own instead of a database you rent.

View details
88
Repo Health
90
Technical
64
Dependency
Built with
TypeScript 64%
HTML 13%
Svelte 13%
Updated 5 days ago
TypeScript
92%
Other

n8n

Automation · No Code Platforms

206,147

Code when you need it, UI when you don't — the workflow automation platform built for technical teams who refuse to choose.

View details
95
Repo Health
87
Technical
65
Dependency
Built with
TypeScript 92%
Updated 4 days ago
TypeScript
99%
Other

Papermark

Digital Signiture · File Storage

9,218

Open-source DocSend alternative with page-by-page analytics, secure data rooms, and custom domains for document sharing.

View details
82
Repo Health
63
Technical
67
Dependency
Built with
TypeScript 99%
Updated 1 months ago
TypeScript
99%
Other

Teable

Databases · No Code Platforms

21,838

A no-code PostgreSQL database with spreadsheet UX, real-time collaboration, and native AI agents — built for teams that outgrow Airtable.

View details
79
Repo Health
76
Technical
62
Dependency
Built with
TypeScript 99%
Updated 5 days ago
TypeScript
82%
Other

twenty

CRM

57,585

The open-source CRM you build, ship, and version like the rest of your stack — with customizable objects, AI agents, and a TypeScript SDK.

View details
92
Repo Health
82
Technical
64
Dependency
Built with
TypeScript 82%
MDX 15%
Updated 4 days ago

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