webhttrack ignores LC_ALL/LC_MESSAGES and picks the wrong Chinese and Portuguese#616
Merged
Conversation
xroche
added a commit
that referenced
this pull request
Jul 16, 2026
#616 already takes 61. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Xavier Roche <roche@httrack.com>
xroche
force-pushed
the
fix-webhttrack-locale
branch
from
July 17, 2026 04:48
a62bcbb to
5dcabec
Compare
The launcher resolved LC_MESSAGES/LC_ALL/LANG into HTSLANG, then immediately overwrote it with a value recomputed from $LANG alone, so LC_ALL and LC_MESSAGES were ignored: a user with only LC_ALL=fr_FR.UTF-8 set got English. That same line cut the region off with "cut -f1 -d'_'", leaving the zh_tw and pt_br entries of lang.indexes unreachable, so Traditional Chinese fell back to Simplified and Brazilian Portuguese to European Portuguese. Resolve the locale in POSIX precedence order and look the tag up region-first, falling back to the bare language. Also fix Slovenian's ISO 639-1 code, which was "si" (Sinhala) in both lang.indexes and Slovenian.txt: sl_SI users got English, and the served pages claimed lang="si". Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Xavier Roche <roche@httrack.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Xavier Roche <roche@httrack.com>
The lift ended at the first blank line, so a blank line grown inside the locale block would truncate it: reinstating the old LANG-only bug below one left the test passing 14/14 while the launcher returned English. Anchor on the next section instead, and pin exported-empty as unset, which lang_of cannot express. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Xavier Roche <roche@httrack.com>
xroche
force-pushed
the
fix-webhttrack-locale
branch
from
July 17, 2026 05:06
5dcabec to
52d790b
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
webhttrackresolved the caller's locale intoHTSLANGfromLC_MESSAGES/LC_ALL/LANG, then threw that away on the next line by recomputing it from$LANGalone. SoLC_ALLandLC_MESSAGESwere dead: with onlyLC_ALL=fr_FR.UTF-8set you got English. The same line also cut the region off withcut -f1 -d'_', which left thezh_twandpt_brrows oflang.indexesunreachable, so Traditional Chinese fell back to Simplified and Brazilian Portuguese to European Portuguese. One line, both bugs.The locale is now resolved in POSIX precedence order (
LC_ALLoverLC_MESSAGESoverLANG) and looked up region-first with a fallback to the bare language. That is the policylang.indexesalready implies by carrying bothzh_twandzh; nothing new is invented here. HonouringLC_ALLdoes meanLC_ALL=Cnow wins over a setLANG, so someone withLC_ALL=CandLANG=fr_FR.UTF-8moves from French to English. That is the POSIX-correct reading of what they asked for, and it is the widest behaviour change here.While checking the region lookup I found Slovenian's ISO 639-1 code is simply wrong in the data:
lang.indexesandSlovenian.txtboth saysi, which is Sinhala.sl_SIusers got English, and since htsserver feedsLANGUAGE_ISOinto<html lang=...>, the served pages announced themselves as Sinhala too. Fixed in both files, byte-wise so Slovenian.txt's legacy-charset bytes survive untouched.tests/61_webhttrack-locale.testlifts the locale block out of the launcher and drives it, so it exercises the shipped code rather than a reimplementation of it. On master it fails atzh_TW(want 14, got 13); with the fix the whole table passes.fr_FRmaps correctly on master as well, so the test is not just failing everything put in front of it.This does not close #95 (select system's language by default). The lookup only covers locales
lang.indexesalready lists, and choosing a language for an unlisted locale remains a policy call for the maintainer.