feat(i18n): enable UI translations with a per-user language setting [1/3]#15091
Draft
devGregA wants to merge 5 commits into
Draft
feat(i18n): enable UI translations with a per-user language setting [1/3]#15091devGregA wants to merge 5 commits into
devGregA wants to merge 5 commits into
Conversation
…r the OS promo banner DD_OS_MESSAGE_ENABLED (bool, default True) is a global admin opt-out: when False, get_os_banner() returns None before any network call, so no request is made to the GCS bucket. Default behavior is unchanged. Authenticated users can also dismiss the banner via a close (x) button. The dismissal is stored as a hash of the current message on UserContactInfo (mirroring the ui_use_tailwind preference), so the banner reappears only when the promo text changes. The button posts to a new dismiss_os_message endpoint (form-based CSRF) and hides the banner instantly via JS, degrading to a normal POST when JS is disabled. Includes migration 0270, docs and template-env updates, and unit tests (36 passing in unittests/test_os_message.py). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…utton Moves the dismiss (x) to lead the banner, before the headline, so it is clearly separated from the expand caret and avoids misclicks. Replaces the reused Bootstrap '.close' class (which collided with auto-generated v3 UI styles) with a dedicated 'os-message-dismiss' class styled as a small bordered button. Lays out the OS banner as a centered flex row scoped to [data-source="os"], so the styling applies only to this banner; other banners and the messages notifications are unaffected. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…URE_LOCATIONS TestDismissOsMessageView loaded dojo_testdata.json directly, which raises NotImplementedError under V3_FEATURE_LOCATIONS=True (the fixture contains deprecated Endpoint records). Adding the @versioned_fixtures decorator swaps it to dojo_testdata_locations.json under V3, matching the convention used by the rest of the suite. Test-only change; verified passing locally under both V3=True and V3=False. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Enables Django i18n in the OSS UI and lights up the existing (audited) pt_BR/ru catalogs. settings: add LocaleMiddleware, LANGUAGES (en, pt-br, ru), LOCALE_PATHS. Per-user language: UserContactInfo.language (migration 0271) + a profile selector. The DB is the cross-device source of truth; the django_language cookie caches it so LocaleMiddleware resolves per request with no DB access. The cookie is seeded from the DB only when absent (~once per browser session) and refreshed on change; /api/ requests are skipped (they localize via Accept-Language). Build: compile .mo into the image via msgfmt (the .mo are gitignored), debian + alpine. Also fixes 3 malformed entries in the pre-existing pt_BR catalog so it compiles. Only en/pt-br/ru are offered (audited); es/ja/de/fr are added once translated. Stored DB values and serialized API responses stay English regardless of language. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
github-actions
Bot
added
docker
New Migration
devGregA
changed the title
…config Adds unittests/test_i18n.py: set_language_cookie sets/clears the cookie; LanguagePreferenceMiddleware seeds+activates from the DB only when the cookie is absent, and is a no-op for present cookies, /api/ paths, anonymous users, and users with no stored preference; and config checks (LocaleMiddleware enabled, preference middleware after auth, offered languages, LOCALE_PATHS). 11 tests, SimpleTestCase (no DB). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Contributor
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
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.
DefectDojo's templates and models are already full of translation markers
(
{% trans %},gettext), and there are even committed pt_BR and ru catalogs,but the runtime was never wired up, so nothing actually translated. This turns
it on and adds a per-user language preference.
What's here
LocaleMiddleware,LANGUAGES, andLOCALE_PATHS.languagefield onUserContactInfo(migration0271)and a selector on the profile page.
across devices, and it's cached in the standard
django_languagecookie thatLocaleMiddlewarereads on each request. We only touch the DB to seed thecookie when it's missing (roughly once per browser session) and to refresh it
when the user changes their language, so the steady state has no extra
per-request query. API requests are skipped and keep honoring
Accept-Language..mocatalogs into the image at build time (debian and alpine);the
.mofiles stay gitignored.Languages
English, Portuguese (Brazil), and Russian are offered for now. The pt_BR and ru
catalogs already existed but were never compiled or shipped, so I reviewed them
for broken format placeholders, injected markup, and the wording on
destructive/security actions and found nothing off (and fixed 3 malformed pt_BR
entries that were preventing the catalog from compiling at all). Spanish,
Japanese, German, and French get added once their translations are done.
Scope / non-goals
of the selected language; only displayed text changes. Localizing API responses
and the OpenAPI schema is deliberately left to a follow-up so existing
integrations aren't affected.
and the remaining hardcoded template strings that aren't marked yet (which is
why some form fields still render in English here).
Based on #15089 (OS message opt-out). If that hasn't merged yet, its commits will
show up in this diff.
Testing
Verified on a local instance: switching a user's language renders the UI in
Portuguese/Russian and falls back to English.
compilemessagessucceeds for allcatalogs and ruff passes.