What happened
While translating the bn (Bengali) batch, I noticed many pre-existing msgstr entries in locale/bn/messages.po are actually in Hindi (Devanagari script), not Bengali. These entries are not part of my batch's untranslated pool (they already have non-empty msgstr, so ./i18n untranslated bn skips them), but they are visibly wrong to a Bengali reader.
A rough scan found 1486 lines containing Devanagari-range characters (U+0900–U+097F) in msgstr values — Bengali script uses a distinct Unicode block (U+0980–U+09FF), so these ranges never overlap; any match is contamination, not a false positive.
Examples
msgid "%(count)d work"
msgid_plural "%(count)d works"
msgstr[0] "%(count)d किताब"
msgstr[1] "%(count)d किताबें"
msgid "Batch Imports"
msgstr "आयात"
msgid "There is one person ahead of you in the waiting list."
msgid_plural "There are %(count)d people ahead of you in the waiting list."
msgstr[0] "प्रतीक्षा सूची में आपसे आगे एक व्यक्ति है।"
msgstr[1] "प्रतीक्षा सूची में आपसे आगे %(count)d लोग हैं।"
msgid "%d Current Loan"
msgid_plural "%d Current Loans"
msgstr[0] "%d वर्तमान ऋण"
msgstr[1] "%d वर्तमान ऋण"
All of the above are grammatically valid Hindi, not Bengali — it looks like Hindi translations were pasted into the Bengali locale file at some point (likely accidentally, given the file also contains a great deal of correct Bengali).
Impact
Bengali-speaking users see a mix of Bengali and Hindi throughout the site. This predates the current AI translation batches (these entries are already "translated" so the untranslated-string pipeline never touches them) and won't be fixed by future AI translation runs.
Suggested fix
A validator/lint step that flags msgstr entries containing script ranges inconsistent with the target language's expected script (e.g. Devanagari in bn, or CJK ranges leaking into a non-CJK locale) would catch this class of bug automatically. Someone should also do a one-time audit-and-reset of locale/bn/messages.po to clear the contaminated entries so they re-enter the untranslated pool for correct re-translation.
Batch context
Found during AI translation batch for bn (2026-07-03), PR #19.
What happened
While translating the
bn(Bengali) batch, I noticed many pre-existingmsgstrentries inlocale/bn/messages.poare actually in Hindi (Devanagari script), not Bengali. These entries are not part of my batch's untranslated pool (they already have non-emptymsgstr, so./i18n untranslated bnskips them), but they are visibly wrong to a Bengali reader.A rough scan found 1486 lines containing Devanagari-range characters (U+0900–U+097F) in
msgstrvalues — Bengali script uses a distinct Unicode block (U+0980–U+09FF), so these ranges never overlap; any match is contamination, not a false positive.Examples
All of the above are grammatically valid Hindi, not Bengali — it looks like Hindi translations were pasted into the Bengali locale file at some point (likely accidentally, given the file also contains a great deal of correct Bengali).
Impact
Bengali-speaking users see a mix of Bengali and Hindi throughout the site. This predates the current AI translation batches (these entries are already "translated" so the untranslated-string pipeline never touches them) and won't be fixed by future AI translation runs.
Suggested fix
A validator/lint step that flags
msgstrentries containing script ranges inconsistent with the target language's expected script (e.g. Devanagari inbn, or CJK ranges leaking into a non-CJK locale) would catch this class of bug automatically. Someone should also do a one-time audit-and-reset oflocale/bn/messages.poto clear the contaminated entries so they re-enter the untranslated pool for correct re-translation.Batch context
Found during AI translation batch for
bn(2026-07-03), PR #19.