opendatalab/MinerU · error · ValueError

Language {lang} not supported

Error message

Language {lang} not supported

What it means

Raised by the internal normalize_lang() when a language string, after alias normalization (e.g. east-slavic/arabic/cyrillic/devanagari alias groups collapsing to canonical keys, Chinese aliases to 'ch'), is still not present in the caller-supplied supported_langs set. Unlike the public-API check (error 150), the allow-list here is dynamic: supported_langs reflects the languages the loaded OCR model actually supports (e.g. the Anglo-Slavic mixed model accepts only ch/en/east_slavic). The raw, un-normalized lang appears in the message.

Source

Thrown at mineru/utils/ocr_language.py:156

    supported_langs=None,
) -> str:
    """将 OCR 语言参数归一为模型配置 key,保留内部 seal 与语系短码能力。"""
    normalized_lang = lang or "ch"
    if device == "cpu" and normalized_lang == "seal":
        normalized_lang = "seal_lite"
    elif normalized_lang in _CH_LANG_ALIASES:
        normalized_lang = "ch"
    elif normalized_lang in _EAST_SLAVIC_LANG_ALIASES:
        normalized_lang = "east_slavic"
    elif normalized_lang in _ARABIC_LANG_ALIASES:
        normalized_lang = "arabic"
    elif normalized_lang in _CYRILLIC_LANG_ALIASES:
        normalized_lang = "cyrillic"
    elif normalized_lang in _DEVANAGARI_LANG_ALIASES:
        normalized_lang = "devanagari"

    if supported_langs is not None and normalized_lang not in supported_langs:
        raise ValueError(f"Language {lang} not supported")
    return normalized_lang

View on GitHub (pinned to 4fe4bde114)

Solutions

  1. Match the language to the loaded model: with the standard ch/east_slavic models use 'ch', 'en', 'east_slavic' (aliases accepted); for other languages you need a model variant whose supported_langs includes them.
  2. Pre-check your language list against the same supported set the pipeline uses (inspect the model config / PUBLIC_OCR_LANGUAGES for the public API) before starting a long parse job.
  3. If multiple languages are needed, ensure every entry in lang_list passes — one bad entry aborts the whole list.

Example fix

# before
result = pipeline_backend.parse(pdf_bytes, lang_list=['fr'])  # ValueError: Language fr not supported

# after
result = pipeline_backend.parse(pdf_bytes, lang_list=['ch', 'en'])
Defensive patterns

Strategy: validation

Validate before calling

from mineru.utils.ocr_language import normalize_lang

SUPPORTED = {'ch', 'en', 'east_slavic'}  # mirror the loaded model's supported_langs
langs = ['ch', 'en', 'east_slavic']
for l in langs:
    normalized = normalize_lang(l)  # raises if alias table rejects it
    assert normalized in SUPPORTED, f'{l} -> {normalized} not supported by loaded model'

Type guard

from typing import TypeGuard

def is_supported_lang(lang: object, supported: set[str]) -> TypeGuard[str]:
    if not isinstance(lang, str):
        return False
    try:
        return normalize_lang(lang, supported_langs=supported) in supported
    except ValueError:
        return False

Try / catch

try:
    normalized = normalize_lang(lang, supported_langs=SUPPORTED)
except ValueError:
    # drop the language with a warning instead of aborting the whole document
    logger.warning('unsupported OCR language %s skipped', lang)
    normalized = None

Prevention

When it happens

Trigger: Passing lang='french' (or any language outside the active model's supported_langs) into pipeline code that calls normalize_lang with the loaded model's language set — e.g. using the default ch/en model and requesting 'french' or 'japan'.

Common situations: Assuming all PaddleOCR languages are available because the docs mention them, while the loaded model variant supports only a subset; switching OCR model files without updating the language config; a config file carries a language valid for a previous MineRU version but no longer in the active set.

Related errors


AI-assisted analysis of opendatalab/MinerU@4fe4bde114 (2026-08-14). Data as JSON: /api/errors/12778026244c5217. Report an issue: GitHub.