* web/xliff: remove legacy Transifex-named locale files
The old Transifex config named locale files with underscores
(cs_CZ.xlf, pt_BR.xlf, ...) alongside the hyphenated BCP-47 form the
current lit-localize pipeline actually reads. That config was fixed
months ago, so the underscore files are either stale duplicates of a
current kebab-case sibling or orphaned contributions for locales the
project never enabled.
Deleted 11 legacy files that already have a kebab-case equivalent in
web/xliff/. Kebab wins even where the two diverged, so 2,220 legacy-only
<trans-unit> targets get dropped along the way (fr_FR carried the bulk
at 954; the rest of the languages contribute the remaining 1,266).
Renamed 3 legacy files with no kebab counterpart and added their locale
codes to web/lit-localize.json targetLocales:
- ar_AA.xlf -> ar.xlf (AA was a bogus private-use region; landed on
the plain language code).
- bg_BG.xlf -> bg-BG.xlf.
- no_NO.xlf -> nb-NO.xlf (no is the Norwegian macrolanguage; the
translation is Bokmal, so nb is the correct language subtag).
Each renamed file also has its internal target-language attribute
updated to match its new locale code, so lit-localize keeps
recognising the existing translations instead of treating everything
as absent.
Wired the new locales into LocaleLoaderRecord in
web/src/common/ui/locale/definitions.ts so the runtime can import the
emitted modules; lit-localize regenerates web/src/locale-codes.ts to
match. locale/ (Django gettext) stays exactly as it was.
Verified with: cd web && npm run build-locales && npm run precommit.
Co-Authored-By: Agent (authentik-m-remove-legacy-intended-nominal-mahogany) <279763771+playpen-agent@users.noreply.github.com>
* locale: sync Django language codes to lit-localize (ar_AA to ar, no_NO to nb_NO)
Mirror the two locale-code changes just landed on the web/xliff side
into the Django gettext tree, in Django's ll_CC underscore form:
- locale/ar_AA -> locale/ar (drop the bogus AA private-use region;
matches web ar).
- locale/no_NO -> locale/nb_NO (Norwegian macrolanguage to Bokmal,
which is the writing system the contributed translation uses;
matches web nb-NO).
bg_BG is left alone (already equals the underscore form of the web
bg-BG), and every other Django locale directory - including zh-Hans
and zh-Hant - stays exactly as it was.
Both catalogs also had their in-file Language header updated to match
the new directory (Language: ar_AA -> ar, Language: no_NO -> nb_NO)
and the .mo binaries were recompiled via manage.py compilemessages so
runtime lookups get the correct language metadata.
No functional LANGUAGES / LANGUAGE_CODE settings referenced the old
codes: only historical Transifex team URLs in the .po Language-Team
headers and past release-notes lines mention them, and those are
metadata / audit trail rather than config.
Verified: to_locale('nb-no') -> 'nb_NO', to_locale('ar') -> 'ar', and
gettext.translation loads locale/ar/LC_MESSAGES/django.mo (1,122
entries, language=ar) and locale/nb_NO/LC_MESSAGES/django.mo (1,116
entries, language=nb_NO).
Co-Authored-By: Agent (authentik-m-remove-legacy-intended-nominal-mahogany) <279763771+playpen-agent@users.noreply.github.com>
---------
Co-authored-by: Agent (authentik-m-remove-legacy-intended-nominal-mahogany) <279763771+playpen-agent@users.noreply.github.com>