NLLB-200 Language Codes: Search and Copy the 202 Model Tokens

NLLB uses language-and-script codes such as eng_Latn, not short labels such as en. Use the full code for the source language and the intended target. The distinction matters especially when a language has more than one writing system.

The searchable reference below contains 202 language-and-script entries from the Hugging Face NLLB tokenizer implementation. Language names are matched to Meta’s FLORES reference, with the script identified where needed. The model is called NLLB-200; the number of code entries also reflects script variants.

Find and copy a language code

Search by language name, the whole code or a script suffix such as Latn. The complete table remains available if JavaScript is disabled.

Common codes at a glance

Language or written form	Code
English	eng_Latn
French	fra_Latn
German	deu_Latn
Spanish	spa_Latn
Portuguese	por_Latn
Modern Standard Arabic	arb_Arab
Hindi	hin_Deva
Japanese	jpn_Jpan
Korean	kor_Hang
Simplified Chinese	zho_Hans
Traditional Chinese	zho_Hant
Cantonese in traditional characters	yue_Hant

Copy the code exactly, including the underscore and capitalization. A country code such as US or a locale such as en-US belongs to a different naming system and is not an interchangeable NLLB token.

Read the language and script separately

The first part identifies the language; the second identifies the script. For example, eng_Latn combines English with Latin script. In zho_Hans and zho_Hant, the language portion is shared while the script portion differs.

Choose the code that matches the text you actually have. If your source is written in traditional Chinese characters, record that explicitly in your workflow. For the target, decide which written form your reader needs before generating a translation.

Some languages have multiple entries. The table includes Acehnese in Arabic and Latin scripts, Kashmiri in Arabic and Devanagari scripts, and Tamasheq in Latin and Tifinagh scripts. Searching the language name shows those choices together so you do not accidentally select the first unfamiliar token in a long list.

Use the code with a tokenizer

The Transformers NLLB documentation shows how to set the source language and choose the target language during generation. This small example focuses on checking the tokenizer configuration:

from transformers import AutoTokenizer

model_id = "facebook/nllb-200-distilled-600M"
source_code = "eng_Latn"
target_code = "zho_Hans"

tokenizer = AutoTokenizer.from_pretrained(model_id, src_lang=source_code)
target_id = tokenizer.convert_tokens_to_ids(target_code)
assert target_id != tokenizer.unk_token_id, "Unknown target language code"

For generation, the documented workflow passes the target language token ID as forced_bos_token_id to the model’s generate call. Keep the source code, target code and model identifier together in your configuration so a later change is easy to audit.

If you are setting up the surrounding environment, our local NLLB setup guide covers that next step. Check the current library documentation when adapting a code example to your installed version.

Four mistakes to check before debugging the model

A short locale was supplied. Replace values such as en, zh-CN or ja with the matching NLLB code from the table. Keep your application’s locale-to-model-code mapping explicit.

The source language was left at a default. Set the language of the actual input when constructing or configuring the tokenizer. A target-language choice does not also describe the source text.

The right language has the wrong script. Compare the suffix with the writing system required for your output. Keep both Chinese written forms visible in your configuration rather than hiding them under a single ambiguous “Chinese” option.

A code came from a different list. FLORES is a related evaluation resource, while the tokenizer defines the code tokens used by this model implementation. This lookup uses the tokenizer’s entries and joins the descriptive names from FLORES. If you use a different model or tokenizer, inspect that implementation’s own supported tokens.

A small validation checklist for your project

1. Save the model identifier and library version with your experiment.
2. Confirm the source and target codes are present in the tokenizer you loaded.
3. Start with a short sentence whose language is known.
4. Check the output script and have a competent reader review meaning.
5. Keep representative examples from your own use case for later comparisons.

Successful token lookup is the configuration check. Translation quality still needs evaluation on your actual material, particularly for names, numbers and domain-specific language. Record those checks alongside the code mapping so a passing setup check is not mistaken for a completed quality review.

Model use and license

Meta’s 600M model card identifies NLLB-200 as a research model under CC BY-NC 4.0. It describes sentence translation as the intended use and lists limitations for production deployment, specialized medical or legal text and document translation. Review those terms before choosing it for an application.

This page is a code reference: filtering and copying a language token does not run a translation model. Use the model card and your own evaluation to decide whether the underlying model fits your project.

Sources

• Hugging Face: NLLB tokenizer implementation
• Meta: FLORES-200 language reference
• Hugging Face: Transformers NLLB documentation
• Meta: NLLB-200 distilled 600M model card