Skip to main content
Glama
anzy-renlab-ai

Pronounce / pronounce-mcp


πŸš€ Try it in 30 seconds

git clone https://github.com/anzy-renlab-ai/pronounce.git
cd pronounce && ./install.sh
say-it kubectl

say-it CLI demo β€” kubectl, YAML, TOML, Ghostty

That's it. Now try say-it GIF, say-it nginx, say-it Pydantic, say-it --why JSON, or say-it quiz for a 10-question challenge. Linux users: install espeak-ng (sudo apt install espeak-ng) and the CLI just works. Windows: same CLI under WSL or git-bash + PowerShell. Or skip install and use the browser at pronounce.renlab.ai.

⭐ If say-it kubectl saves you one cringey standup moment β€” star the repo. It nudges more devs to contribute their favorite mispronounced project name.


Related MCP server: wordorb

πŸ† The developer pronunciation scoreboard

1,903 entries β€” 1,283 carry a citable source β€” 108 settled by the creator themselves, 175 the community still argues about. The famous ones:

βœ… Settled β€” the creator said so

Word

It's…

…not

Settled by

GIF

"jif"

"ghif" (hard-G speech cue)

Steve Wilhite (creator), NYT 2013

nginx

"engine X"

"n-jinx"

NGINX official

YAML

"yam-ul"

"yammel"

yaml.org

GNU

"guh-NEW" (hard g)

"noo"

GNU Project

LaTeX

"lay-tek"

"lay-teks"

Lamport / LaTeX project

TOML

rhymes with "knoll"

"tom-el"

Tom Preston-Werner (creator)

Tcl

"tickle"

"T-C-L"

John Ousterhout (creator)

awk

"auk" (like the bird)

"A-W-K"

Aho / Weinberger / Kernighan

βš”οΈ Still contested β€” both readings are in active use

Word

Camp A

Camp B

kubectl

"koob-control"

"cube-cuddle"

SQL

"sequel"

"S-Q-L"

JSON

"JAY-son"

"JEE-son"

GUI

"gooey"

"G-U-I"

JWT

"jot" (per RFC 7519)

"J-W-T"

Every cell has IPA and audio; 1,283 also carry a citable source. Browse all 1,903 entries β†’

Disagree with one? That's the whole point β€” open a PR with your reading and a source. The argument is the dataset.


What you're actually getting

  • 1,903 entries β€” 1,283 carry a citable source. Confidence-tagged (creator-clarified / community-consensus / contested), each with a citable URL where one exists (we'd rather leave it blank than fabricate one). Wilhite said GIF is "jif" at the 2013 Webby Awards. Crockford says JSON is "JAY-son" (RailsConf 2009). RFC 7519 says JWT is "jot". The dictionary cites them.

  • Multi-reading audio. For words where the debate is real β€” GIF, SQL, GUI, char, regex β€” the CLI chains the alternates after the primary with a spoken "or:" so you hear the debate without staring at the terminal. --solo skips the tail once you've internalized it.

  • One Bash CLI, no npm runtime. No sudo, no framework bootstrap, no surprises. It detects macOS say, Linux espeak-ng/espeak, or Windows PowerShell System.Speech. The repo also ships a Claude Code skill and an MCP server so your AI answers "how do you pronounce X?" with audio, not a phonetic guess.

  • A docs-native GitHub Action. Scan Markdown changed by a pull request and emit a sourced pronunciation glossary in the job summary β€” no API key, dependency install, or network request.

  • Canonical website audio. The site plays each committed canonical MP3 first and uses Web Speech only as a fallback if playback fails.

$ say-it --why JSON
word              JSON
ipa               /ˈdΚ’eΙͺsΙ™n/
respelling_us     jay son
confidence        contested
source            Wikipedia Β§ Pronunciation
url               https://en.wikipedia.org/wiki/JSON#Pronunciation

Why not just Google?

Because Google gives you 47 Reddit arguments and a YouTube clip you have to unmute. IPA gives you /ˈkuːb kΙ™nˌtroʊl/ β€” a reference, not a teacher.

You don't need a phonetic transcription. You need to hear the word. Twice. Maybe three times. Done.

say-it ships a community-maintained dictionary of how engineers actually say the names that trip everyone up β€” and feeds the intended respelling to your OS's text-to-speech engine, so kubectl comes out as koob-control, not whatever your computer guessed from the letters.

Famous moments

Some pronunciations aren't opinions β€” the creators settled them. The dictionary cites every one:

Word

Reading

Source

GIF

"jif" (creator says so)

Steve Wilhite, Webby Awards 2013

JSON

"jay-son"

Douglas Crockford, RailsConf 2009

GNU

"g-noo" (hard G, one syllable)

GNU Project official

Linux

"LIN-ux" (short i, schwa)

Linus Torvalds himself

LaTeX

"lay-tek" (or "lah-tek")

Leslie Lamport, official

Django

"JANG-go" (silent D)

Django FAQ

Vue

"view" (one syllable)

Evan You, Vue docs

Vite

"veet" (French for quick)

Vite docs

Knative

"KAY-native" (the K is voiced)

Knative docs

etcd

"et-cee-dee" (et-cetera-distributed)

etcd FAQ

Run say-it --why <word> to see the citation when an entry has a source_url; unsourced entries are left blank rather than given a fabricated URL.

Install

brew install anzy-renlab-ai/tap/say-it   # Homebrew on macOS

Or the "Try it in 30 seconds" block above. ./install.sh drops:

  • the CLI at ~/.local/bin/say-it,

  • the pronunciation dictionary at ~/.local/share/say-it/pronunciations.tsv,

  • if you use Claude Code, a pronounce-word skill at ~/.claude/skills/pronounce-word/ so any "how do you say X?" prompt to your AI gets answered with audio instead of IPA,

  • the same skill into ~/.agents/skills/ (Codex CLI) and ~/.kiro/skills/ (Kiro) when those dirs exist β€” it's the cross-tool Agent Skills standard.

Make sure ~/.local/bin is on your $PATH. Linux also works β€” install espeak-ng (sudo apt install espeak-ng / brew install espeak-ng). Windows: WSL or git-bash + PowerShell. Or skip install entirely with the browser version at pronounce.renlab.ai.

Usage

say-it kubectl                    # primary Γ— 3, then "or: <alt>" for each alternate
say-it --solo kubectl             # primary only β€” silence the "or:" tail
say-it --alt GIF                  # focus on the first alternate
say-it --alt 2 GUI                # focus on the Nth alternate (1-indexed)
say-it --all SQL                  # primary AND every alternate, each repeated
say-it --no-dict kubectl          # bypass the dictionary entirely
say-it --why JSON                 # show IPA, source URL, category, confidence
say-it list                       # every word in the dictionary
say-it search redis               # grep the dictionary (case-insensitive)

say-it -n 5 Pydantic              # 5 repetitions instead of 3
say-it -r 110 Knative             # slower (110 wpm; default is 130)
say-it -o /tmp/word.aiff Postgres # save to file instead of playing
say-it --list                     # all macOS voices

The default macOS voice is Samantha (General American); -v <voice> selects another macOS voice. Linux and Windows use their detected backend's English voice. The dictionary is GenAm-only, by design.

Claude Code integration

Install the cross-tool Agent Skill directly with GitHub CLI:

gh skill install anzy-renlab-ai/pronounce pronounce-word
You:    kubectl ζ€ŽδΉˆθ―»οΌŸ
Claude: πŸ”Š (plays "koob-control" three times)
        /ˈkuːb kΙ™nˌtroʊl/ β€” "KOOB-control". Kelsey Hightower says it
        this way (KubeCon talk). "Cube-cuddle" is an alternate β€”
        try `say-it --alt kubectl` to hear it.

Once installed, the pronounce-word skill auto-triggers on:

  • X ζ€ŽδΉˆθ―» / X ζ€ŽδΉˆε‘ιŸ³ / θ―»δΈ€δΈ‹ X

  • how do you pronounce X / pronounce X / how do you say X

Your AI replies with sound, not just a phonetic guess. Skill file: skills/pronounce-word/SKILL.md.

Not on Claude? Same skill drops into Codex CLI (codex plugin marketplace add anzy-renlab-ai/pronounce) and Kiro (~/.kiro/skills/), and the MCP server covers Claude Desktop, Cursor, Continue, Zed, Cline & friends β€” full matrix in integrations/.

Add to Kiro

GitHub Action β€” pronunciation guides for docs

Add a pronunciation glossary to every documentation pull request:

- uses: actions/checkout@v7.0.1
  with:
    fetch-depth: 0
- id: pronounce
  uses: anzy-renlab-ai/pronounce@v2.28.1

Pronounce Docs scans changed Markdown/MDX and writes a table containing each matched term, its IPA, plain-English respelling, audio page, and creator or official source where available. It runs locally from the repository snapshot: no token, API key, telemetry, package install, or network request. See the complete setup, inputs, and outputs.

VS Code extension

Install from VS Code Marketplace Install from Open VSX

Pronounce demo β€” kubectl, YAML, Ghostty, wagmi

Hover over any tech word in any file β€” see the IPA, hear the pronunciation. Same 1,903-entry dictionary as the CLI, JSON-bundled at build (zero runtime parse cost).

# Cursor / VSCodium / Zed / Gitpod / Theia / code-server (Open VSX)
code --install-extension sayit.pronounce
# or the listing: https://open-vsx.org/extension/sayit/pronounce

Now live on Microsoft Marketplace too: ext install sayit.pronounce in VS Code. See marketplace listing.

  • Hover over kubectl, YAML, Ghostty, wagmi… β†’ tooltip with IPA + πŸ”Š Play + β˜… Star link.

  • βŒ˜β‡§' β€” speak selection.

  • Status bar πŸ”Š sayit β€” click to speak the current selection.

  • Welcome walkthrough β€” 4-step onboarding on first install.

  • Pronounce: Search dictionary… β€” fuzzy-find all 1,903 entries.

Source: integrations/vscode/. Cross-platform as of v0.3 β€” macOS say, Linux espeak-ng, Windows PowerShell.

Chrome / Edge / Brave extension

Click any tech word on any webpage β†’ popup with IPA + audio. Same 1,903-entry dictionary. The extension speaks through Web Speech; pronounce.renlab.ai plays the committed MP3 corpus first and reserves Web Speech for fallback. Sideload only for now (not yet on Chrome Web Store).

Download pronounce-chrome-0.3.1.zip β†’ unzip β†’ chrome://extensions/ β†’ Developer mode β†’ Load unpacked.

Source: integrations/chrome/.

How the dictionary works

data/pronunciations.tsv is the single source of truth β€” tab-separated, 1,903 entries, covering:

  • Cloud / DevOps: kubectl, nginx, Kubernetes, helm, Istio, Envoy, Prometheus, Grafana, Terraform, Argo, Knative, etcd, containerd, runc, Podman, ...

  • Languages / Frameworks: Django, Vue, Vite, Pydantic, Bun, Deno, Hugo, Hono, Caddy, Svelte, Astro, Pinia, ...

  • Databases: PostgreSQL, Postgres, SQLite, MySQL, MongoDB, Cassandra, Redis, Ceph, ScyllaDB, ClickHouse, DuckDB, ...

  • CS jargon / acronyms: GIF, JSON, SQL, GUI, GNU, char, regex, sudo, tmux, chmod, WYSIWYG, ASCII, enum, NaN, SaaS, PaaS, ...

  • Distros / tools: Linux, Debian, Ubuntu, Arch, Nix, LaTeX, TeX, emacs, zsh, ...

Each entry has 10 columns: word | ipa | respelling_us | alt_ipa | alt_respelling_us | source_url | source_label | category | confidence | notes. respelling_us is plain English-like input passed to the detected OS TTS backend, so the intended reading is spoken instead of asking the engine to guess from the project name.

Local override: drop a ~/.config/say-it/pronunciations.local.tsv and it takes precedence.

What works today

  • βœ… macOS β€” built-in say.

  • βœ… Linux β€” espeak-ng (preferred) or espeak.

  • βœ… Windows β€” PowerShell System.Speech from the same Bash CLI under Git Bash/MSYS2/Cygwin.

  • βœ… 1,903 entries; 1,283 carry a citable source β€” the rest are confidence-tagged, no fabricated citations.

  • βœ… Audible multi-reading awareness β€” contested words audibly chain alternates with "or:".

  • βœ… --alt [N], --all, --solo, --why, --json, --md, --no-dict, list, search, quiz, repl, stream, doctor, export, benchmark, badge, cheatsheet.

  • βœ… Claude Code skill + MCP server for AI-side pronunciation questions.

  • βœ… GitHub Action β€” sourced pronunciation glossaries for Markdown pull requests.

  • βœ… Browser PWA β€” installable, offline-capable, instant search, voice-mic search, interactive quiz.

  • βœ… Editor integrations β€” Raycast, Alfred, VS Code, Cursor, Codex, Kiro, Continue.

  • βœ… 🌐 Live site β€” pronounce.renlab.ai (1,903 entries browsable with audio; 1,283 sourced entries) + /zh (Chinese landing).

What's coming

See DESIGN.md for the architecture.

  • ☁️ Cloud TTS (opt-in ElevenLabs / OpenAI) for the names native TTS still mangles.

  • πŸ“š Anki export for vocabulary drills.

  • πŸŒ— Light theme on the v2 homepage (already shipped on word/SEO pages).

Contributing

Two things we want most:

  1. Pronunciation entries. Open a PR adding a row to data/pronunciations.tsv. Required columns: word, ipa, respelling_us. Highly preferred: source_url (creator interview, conf talk, official FAQ β€” anything verifiable). Contested readings are welcome; put the rival in alt_* columns and we'll wire --alt through.

  2. Backend quality. macOS (say) is the gold standard; the Linux (espeak-ng) and Windows (PowerShell) backends ship but are best-effort β€” help us close the gap. See DESIGN.md Β§Backends.

Keep it tiny. Keep it dep-free where possible. Keep the defaults opinionated (3 reps, GenAm, Samantha voice).

⭐ Support β€” start with a star

The dictionary is free and MIT. The single highest-leverage thing you can do is star the repo β€” it's the signal that pulls in more contributors, more PRs, more creator-clarified entries.

Optional, if it's saved you real standup pain:

Dollars cover hosting (Vercel/Cloudflare/Open VSX), domain renewals, MiniMax narration credits for promo videos, and time to track down creator citations for new entries.

Contributors

Every entry, source upgrade, and skill fix counts. Open a PR β€” your face shows up here.

License

MIT β€” see LICENSE.


IPA is a reference. Audio is a teacher.

Available Tools

3 tools
list_pronunciationsA

List dictionary entries, optionally filtered by category.

Categories include: product, project, cli-tool, tool, cs-term, acronym, abbreviation, person. The dictionary holds well over 1500 entries and grows continuously, so the unfiltered list is large β€” pass category and/or limit to keep the result focused.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
categoryNo

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A3.6/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided. The description discloses that the dictionary is large and growing, and that unfiltered lists are big. This adds some behavioral context, but could mention more about response structure or performance.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Concise two-sentence description with clear bullet-like list of categories. Front-loaded with purpose. Could be slightly more structured but is efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given output schema exists (but not shown), description covers param guidance. Lacks mention of authentication or pagination behavior beyond limit, but is sufficient for a list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema has 0% description coverage, but the description explains the purpose of category (listing possible values) and limit (keeping results focused), compensating for the lack of param descriptions. However, missing details like default limit value are already in schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it lists dictionary entries with optional category filtering. It distinguishes from siblings implicitly (list vs search), but does not explicitly contrast with 'search_pronunciations'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides advice to use category and limit for focused results, but does not specify when to use this tool over the sibling 'search_pronunciations' tool, nor when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

pronounceA

Look up the canonical pronunciation of a developer-related word.

Returns the IPA, a respelling that approximates how engineers actually say the word, a playable MP3 audio_url, optional alternate readings, the source citation when available, and editorial notes. Use this for project names like kubectl, nginx, GIF, JSON, Pydantic, Knative, programmer jargon, and tech acronyms. Returns an error dict if the word is not in the dictionary; for general English vocabulary, fall back to your own knowledge.

ParametersJSON Schema
NameRequiredDescriptionDefault
wordYes

TDQS

A4.5/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses the return content (IPA, respelling, audio_url, alternate readings, source citation, editorial notes) and error behavior (error dict if word not found). It does not mention authentication or rate limits, but as a read-only lookup, this is acceptable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise with four sentences, each adding value. It is front-loaded with the main purpose, followed by return details, usage scope, and error handling. No superfluous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple input and no output schema, the description covers all essential aspects: purpose, return fields, error case, and scope limitations. It is sufficiently complete for an agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter 'word' is described implicitly through examples and scope (developer-related word). Schema coverage is 0%, so the description compensates by providing context that the word should be a tech term or acronym, which adds meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool looks up canonical pronunciations for developer-related words, with specific examples (kubectl, nginx, GIF, etc.). It distinguishes from siblings like list_pronunciations and search_pronunciations by focusing on a single word lookup.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says when to use the tool ('Use this for project names like...') and when not to ('for general English vocabulary, fall back to your own knowledge'). However, it does not compare directly to sibling tools, which could provide more precise guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_pronunciationsA

Search the dictionary by partial word or category match.

Matches substrings against the entry's word and category only β€” the search index (/api/words.json) carries no notes or source text, so a query like "Kelsey" will NOT surface kubectl. To read an entry's notes, look it up with pronounce.

Returns a list of matching entries with word, slug, category, and confidence. Use this when the exact spelling is unknown or when browsing entries by category.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
queryYes

Output Schema

ParametersJSON Schema
NameRequiredDescription
resultYes

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full behavioral burden, and it delivers: it explains the search index limitation, the negative example with 'Kelsey' and `kubectl`, the fields returned, and the fact that notes are not searchable. This is far more than a generic 'Search' claim.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose, then adds a necessary limitation, a return-shape summary, and a usage guideline. Every sentence contributes something non-redundant, and the negative example earns its place by preventing a likely misquery.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter search tool with an output schema, the description supplies the matching semantics, the scope limitation, the returned fields, and when to choose the tool. Nothing essential for correct invocation is missing, and the output schema can handle the precise return structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It clearly defines the `query` semantics as a substring match against `word` and `category`. The `limit` parameter is not described, though its default is in the schema and its meaning is self-evident from the name.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Search the dictionary by partial word or category match.' It further clarifies the matching scope and explicitly contrasts itself with the exact-lookup behavior of `pronounce`, so an agent can distinguish it from siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states when to use this tool ('when the exact spelling is unknown or when browsing entries by category') and when to use an alternative ('To read an entry's notes, look it up with `pronounce`'). This gives clear decision guidance relative to the sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 1 tool updatev2.28.1
    • Addedsearch_pronunciations
  2. 1 tool updatev2.23.0
    • Removedsearch_pronunciations
  3. 3 tool updatesv0.1.1
    • First observedlist_pronunciations
    • First observedpronounce
    • First observedsearch_pronunciations

TDQS

A4.2/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: pronounce for exact word lookup, search_pronunciations for partial/category matching, and list_pronunciations for browsing with filters. The only slight overlap between search and list is clarified by their descriptions.

Naming Consistency4/5

Two tools follow a verb_noun pattern (search_pronunciations, list_pronunciations), while the core tool is just the bare verb pronounce. This is a minor deviation, but the overall naming is predictable and readable.

Tool Count5/5

Three tools is well-scoped for a pronunciation dictionary: lookup, search, and list cover the essential interaction modes without redundancy. Each tool earns its place.

Completeness5/5

For the stated domain of looking up developer-related pronunciations, the surfaces are complete: exact lookup, discovery by partial match, and category-based browsing. There are no obvious dead ends or missing operations.

Maintenance

ActivityActive
ResponsivenessWithin a week

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    C
    maintenance
    Phonetic analysis engine that gives LLMs accurate rhyme detection, stress scanning, meter identification, and syllable counting backed by the full CMU Pronouncing Dictionary.
    5
    MIT
  • F
    license
    Not graded
    quality
    D
    maintenance
    Word Orb is a language enrichment MCP server. 50,000+ words with IPA, definitions, etymology, translations in 47 languages with native script, gender equity guidance, and AI identity ethics. 3ms edge response. Tools: word_enrich, word_ethics, agent_speak. URL: https://mcp.wordorb.ai/mcp
    -
  • A
    license
    Not graded
    quality
    A
    maintenance
    Multilingual name romanization lookup across Chinese, Japanese, Korean, Arabic, Vietnamese, and more. Resolves whether two name spellings refer to the same person β€” Chan/Chen/ι™³/ι™ˆ, Hsu/Xu, Chou/Zhou β€” across Pinyin, Wade-Giles, Cantonese, Hokkien, and other romanization systems.
    MIT