ipa-dict: wordlists with IPA pronunciation for many languages

The gap the project set out to fill

The stated motivation is precise. There is no existing central, standardised location for checking the correspondence between orthography and pronunciation in any given language.

Then it gets more concrete. IPA information even for large languages can be surprisingly difficult to find, and is generally not provided for each form of a word. In many languages, reference works carry pronunciation notation only for lemmas, the headwords, and very little information is available about conjugations and forms of word classes other than the dictionary form. The French example makes the scale plain: each verb may have forty or more conjugated forms, but pronunciation is listed only for the dictionary form.

The third leg of the argument is coverage. Many languages do not have any significant amount of IPA information available at all, even in dictionaries, and this is more likely for language variants and non-standard varieties. That is the case this project cares about most, since a list of twenty-nine entries includes Jamaican Creole, Isan, Cantonese, Khmer and Odia alongside the major world languages.

So the project is doing two things at once. It is filling the inflected forms gap, listing pronunciations for forms that reference works omit, and it is making IPA data exist at all for languages and varieties that have none.

How the pronunciations were produced

The compilation method is described as a combination of manual and semi-automatic generation, and the two halves are applied to different things.

Whenever possible, pronunciations have been checked manually against multiple reference works, particularly for lemmas, which are usually more easily available. That is a deliberate choice about where to spend the human effort, since the lemma is the form a learner meets first and the form the reference works actually contain.

Inflected forms have been either added manually or with semi-automatic guidance when multiple pronunciations can be pre-determined with some certainty. The condition matters. Where a form's pronunciation follows from the lemma with reasonable confidence, a rule can be applied, and where it does not, the project says the forms were added by hand instead.

That distinction is the honest core of the dataset. A grapheme to phoneme system trained on this data inherits the quality of its weakest entries, and the manual checking is strongest on lemmas and weaker on the inflected forms, which is the reverse of the ordering in most published dictionaries.

The README also says that if you find another format that would be useful, you can open an issue or a pull request to add it, which is a small sign that the format list is treated as a living thing rather than a settled specification.

The four formats and what each is for

The data is provided in several formats so that it is useful to both people and programs, and the choice of format is mostly about what you are building.

The raw data is the source form. Each word and its corresponding pronunciation sits on a separate line delimited by tab characters, and the file format is spelled out as entry, tab, IPA. The files are plain text, UTF-8 encoded, with a .txt suffix. The reasoning given for this format is that it is simple, lightweight, human and machine readable, and easily convertible to other common formats.

The JSON form nests the entries under a language key.

{
    "LANG":
        [{
            "ENTRY1":"IPA1",
            "ENTRY2":"IPA2",
            "ENTRY3":"IPA3",
            "ENTRY4":"IPA4"
        }]
}

The XML form uses a per-entry element with an identifier attribute, the item and the transcription as children.

    <IpaEntry EntryID="1">
      <Item>ENTRY</Item>
      <Ipa>/IPA/</Ipa>
    </IpaEntry>

The CSV form is the same data with commas instead of tabs, and it exists for spreadsheet programs, where the point is that you should be able to open the file from the file menu without an import step.

All the filenames refer to the ISO 639-1 language code of the relevant language, so sw.json is a JSON file containing pronunciations for Swahili. That naming convention is the one thing to be consistent about, and it is what lets a downstream tool pick the right file without a lookup table.

The language list and the distinctions inside it

Twenty-nine language codes are listed, and the more interesting information is in the variants.

English appears twice, as en_UK for Received Pronunciation and en_US for General American. French appears twice, as fr_FR for France and fr_QC for Quebec. Vietnamese appears three times, as vi_C for Central, vi_N for Northern and vi_S for Southern, which is an unusual level of granularity for a pronunciation dataset and a good sign about the project's intent.

The rest cover a wide range of the world's languages: Arabic in its Modern Standard form, German, Esperanto, Spanish for Spain and for Mexico, Persian, Finnish, Icelandic, Japanese, Jamaican Creole, Khmer, Korean, Malay in its Malaysian and Indonesian forms, Norwegian Bokmål, Dutch, Odia, Romanian, Swedish, Swahili, Isan, Cantonese and Mandarin.

Two observations follow from the list. First, the coverage is wide and shallow rather than narrow and deep, which is the right shape for a project that wants to make data exist where there is none, and the wrong shape for a project that wants authoritative reference coverage of one language. Second, the variant-level granularity applies unevenly, since several languages appear in only one variety while others appear in three.

The dialect codes are not standard ISO 639-1, since the standard covers languages, and a project consuming these files will need to handle the suffix convention itself rather than expecting a standard lookup to resolve en_UK or vi_N.

The downstream projects and the homonyms package

The value of this dataset is realised in other projects, and the README lists them.

The ipa-dict-dsl project, under the open-dsl-dict organisation, has converted all of the IPA data into DSL format dictionary files for use with dictionary software such as ABBYY Lingvo, GoldenDict and gdcl. Pre-compiled and compressed dictionary files for individual languages are downloaded from that project's releases page. The README describes this as an updated collection of dictionaries and shows a screenshot of one in use.

The IPA Lookup project provides a web interface for searching the dictionaries in different languages, with links to all the available languages on the project homepage, and that homepage is also the repository homepage.

There is also a homonyms package containing all homonyms sorted by IPA reading for each language, with lists available for French, Japanese, Norwegian, Swedish, Cantonese and Mandarin, downloadable from the 1.0 release section.

That package is worth pausing on, because it addresses a problem the base data creates. A dictionary entry with several pronunciations is normal and useful, but an application that has to pick one reading automatically needs to know the alternatives, and sorting the homonyms by IPA reading lets a tool surface the variants rather than silently pick one. The fact that the homonym lists exist for a subset of languages rather than all of them is a coverage note worth reading before assuming the option is there.

The README also names Wiktionary-style use, saying the project provides an accessible source of IPA information that other dictionary projects and electronic dictionaries can draw on rather than adding pronunciations for each entry by hand.

Where ipa-dict is the wrong tool

The first limitation is the uneven depth. The manual checking is strongest on lemmas and the semi-automatic guidance is applied to inflected forms, which means the quality of a given entry depends on where it sits in the paradigm. A model trained on the whole dataset will be learning from a mixture of carefully checked and mechanically derived transcriptions, and the README does not publish a per-language quality score.

The second is the release picture. The recent releases section lists a single tag, 1.0, from 2016-09-20, and the downloadable JSON, XML and CSV artefacts are described as being in the releases section. The last push to the repository was on 2026-10-19, so the data in the repository is current, but the packaged downloads date from 2016. A project that wants the current data has to take the raw files from the repository rather than the release artefacts, and should check which of the two it is actually getting.

The third is that this is a wordlist, not a dictionary. There are no definitions, no parts of speech, no senses, no etymology, no usage notes. It answers how a word is pronounced and nothing else, so it complements a dictionary rather than replacing one.

The fourth is that the transcriptions are for words as written, with no phonetic detail. The IPA used is phonemic, which is the right level for a pronunciation dictionary and for grapheme to phoneme work, and it means a user who needs narrow transcription of connected speech gets nothing from this data.

The fifth is that a dialect code in the filename is not a dialect description. The list gives codes and English labels, and a project that needs to know what conventions a particular transcription follows has to look elsewhere.

ipa-dict compared with Wiktionary, CMUdict and a commercial pronunciation API

The comparison with Wiktionary is the most direct, since the README names it as a project that draws on this data. The difference in approach is that Wiktionary stores pronunciation as a wikitext annotation attached to a full entry, which means the transcription travels with the definition and the etymology and the usage notes, and every contributor edits both at once. ipa-dict stores the transcription on its own, in a machine-readable form with a stable schema, which means a program can consume it without parsing wikitext and a contributor cannot attach a sense to a pronunciation. The cost of that separation is that the two can drift, since a word corrected in Wiktionary does not automatically update the wordlist.

The comparison with CMUdict is a comparison of scope. CMUdict is a pronunciation dictionary for American English, built on the speech community's pronunciations, and it is the standard resource for English text to speech work. ipa-dict covers twenty-nine languages including two English varieties, and it is a different kind of artefact, a wordlist rather than a lexicon with speaker and recording metadata. For American English alone, CMUdict is the more appropriate tool; for a language such as Khmer or Cantonese, ipa-dict is the thing that exists at all.

The third comparison is with a commercial pronunciation service, and the difference in approach is licensing and volume. A commercial API gives you coverage of a very large vocabulary, updated on a schedule, with a service level agreement, at a price per call or per entry. ipa-dict is MIT licensed data that you download once, host yourself, and use without a dependency, and the trade is that the vocabulary size and the update frequency are what a volunteer-compiled project can manage.

For a grapheme to phoneme model, the comparison that matters is a research corpus, and here the value of ipa-dict is that it is real dictionary data rather than generated, which is what distinguishes a model trained on it from one trained on a synthetic pronunciation generator.

Licence, repository shape and what to check first

The licence field on the repository says MIT, with a LICENSE file at the root. The repository itself is minimal, with only three top level entries: the LICENSE, this README, and a data/ directory. There is no code, no build script and no test suite, because the artefact is the data and the formats are simple enough that no tooling is needed to produce them.

The project is not archived and the last push was on 2026-10-19, so the wordlists are actively being extended. The topic tags name dictionaries, g2p, grapheme-to-phoneme, IPA, linguistics, phonemic transcription, phonetic transcriptions, wordlist and language, and the grapheme-to-phoneme tag is a useful signal about who this is for.

Four things to check before you build on it.

Which language code you actually need, and whether the variety you want is the one listed, since en_UK and en_US are different resources and the Vietnamese and French variants differ too. Whether you are reading the raw tab delimited files from the data/ directory or the packaged downloads from the 1.0 release, given that the two are not the same vintage. Whether your use case is one reading per word or needs the homonyms, since the homonym lists exist for only six languages. And what your licensing position is, because the MIT terms are permissive and the data is yours to redistribute, which matters if you are considering using it in a commercial dictionary or a language model training set.

Editorial conclusion

ipa-dict suits a project that needs a broad IPA transcription source for many languages, whether it is a grapheme to phoneme model, a dictionary application, a learner's grammar or a Wiktionary-style project that would otherwise transcribe entries by hand. It is the wrong tool if you need a single language covered exhaustively to scholarly depth, since the coverage is uneven between languages and the transcriptions are not guaranteed uniform. Before using it, check the language code for your variety, because the list distinguishes Received Pronunciation from General American, the three Vietnamese varieties and French in France from French in Quebec, and read the homonyms package if your application has to pick between several readings of the same word.

Frequently asked questions

Official sources

1. License: MIT
2. open-dict-data/ipa-dict on GitHub
3. Project website
4. README
5. Releases