[cderv]

Follow-up to #516 and #517. When babel sets up a language from its .ini file (\babelprovide[import]{spanish}, or the provide=* package option) and the hyphenation patterns are not installed, it silently falls back to the current \language with only an Info line in the log, so check_babel() had nothing to match and the document compiled with the patterns of the wrong language (usually English).

Detection

The Hyphen rules for 'X' set to ... Info line cannot be matched on its own: it also appears for the dialects defined in english.ldf (canadian, australian, ...), and when the patterns were found under another name (e.g. austrian set to \l@ngerman-x-2024-02-28). detect_babel_fallback() pairs the Importing data for 'X' from babel-<code>.ini line with the Hyphen rules line for the same locale (the english.ldf dialects have no Importing line), and flags a fallback when the target of set to differs from the hyphenation language the locale's .ini file expects, modulo language.dat synonyms. A target of \l@nil (no hyphenation) is a fallback too, when the locale expects patterns.

The expected language is resolved from the imported .ini file name rather than the locale name, so custom locale names are covered (\babelprovide[import=es]{myspanish}). For .ini files without a hyphenrules value, the locale name itself is the expected pattern when it is a language.dat name (e.g. swissgerman), and no patterns are expected otherwise (e.g. chinese).

Generated maps

tools/update-hyphen.R now writes three more maps next to .hyphen_map, following the same snapshot pattern as #517:

• .hyphen_synonyms: language.dat synonyms to canonical names, from the synonyms= field of execute AddHyphen (e.g. ngerman-x-latest to ngerman-x-2024-02-28)
• .babel_hyphen_map: babel locale names to the expected hyphenation language, from the name.babel aliases and hyphenrules values of the babel-*.ini files
• .babel_hyphen_codes: babel-*.ini base names (as written in the log) to their hyphenrules value, for custom locale names

The babel maps are read from the babel-*.ini files of the local TeX installation. A hyphenrules value that is not a language.dat name is ignored (e.g. assaseme in babel-as.ini), so a missing package that does not exist is never installed.

The tests use real lualatex logs (babel v26.13, TeX Live 2026) and don't need the network; the CI test checks that lualatex() installs hyphen-spanish for a document with \babelprovide[import]{spanish}.

Export for quarto-cli

quarto-dev/quarto-cli#15082 ports this detection to quarto-cli, which follows tinytex's tables through the regex.tar.gz release asset. The three maps are exported as a new babel-hyphen.json next to regex.json and hyphen.json (from tools/export-regex.R). A separate file rather than new keys in hyphen.json, because quarto-cli copies hyphen.json into a flat map whose values are all TeX Live package names; the existing hyphen.json export is unchanged.

This is #520 reopened from the upstream branch, with the babel-hyphen.json export from #521 merged in.

Fixes #519

[cderv]

While porting detect_babel_fallback() to quarto-cli (quarto-dev/quarto-cli#15082), I ran it on about 40 real lualatex and pdflatex logs (babel 26.13, TeX Live 2026, with hyphen-english, hyphen-french, hyphen-german and dehyph-exptl installed). Two cases are wrong with r1 as it is now.

False positive for languages loaded from an .ldf file. \documentclass[naustrian]{article}\usepackage{babel} (what Pandoc emits for de-AT) logs:

Package babel Info: Importing font and identification data for 'naustrian'
(babel)             from babel-de-AT.ini. Reported on input line 4478.
...
Package babel Info: Hyphen rules for 'naustrian' set to \l@ngerman
(babel)             (\language10). Reported on input line 200.

detect_babel_fallback() returns "dehyph-exptl" although nothing is missing: .babel_hyphen_codes[["de-at"]] is ngerman-x-latest and the .ldf registers ngerman. The same happens for nswissgerman (de-CH, \l@ngerman) and \usepackage[austrian]{babel} (\l@german). From what I can tell in babel.sty, the identification level is only used for \LdfInit, font setup and class options before the .ldf is loaded, and is never followed by the .ini hyphenrules lookup. In all my logs the genuine fallbacks use the plain Importing data level.

Missed detection with the basic level. \babelprovide{spanish} without import logs Importing basic data for 'spanish' followed by Hyphen rules for 'spanish' set to \l@nil. r1 does not accept basic, so nothing is detected.

babel 3.84 (checked in its babel.dtx, not on a real log) also writes the language name without quotes in the Importing line, so r1 matches nothing there either.

Changing r1 to this fixes the three:

r1 = "^Package babel Info: Importing (basic )?data for '?([^' ]+)'? .*from babel-([-.A-Za-z0-9]+)[.]ini.*$"

With it, the naustrian, nswissgerman and austrian logs return character(0), the two \babelprovide{spanish} logs return hyphen-spanish, and every other log is unchanged. tests/test-cran/test-latex.R still passes. I'll add test cases built from these logs.