Skip to content

Fall back when a translation is stored as an empty string - #148

Open
shreyanshj10 wants to merge 1 commit into
zostera:masterfrom
shreyanshj10:fix/issue-139-empty-string-fallback
Open

shreyanshj10 wants to merge 1 commit into
zostera:masterfrom
shreyanshj10:fix/issue-139-empty-string-fallback

Conversation

@shreyanshj10

Copy link
Copy Markdown

When a translation is stored as an empty string in i18n, which happens easily through the admin with ActiveLanguageMixin, the fallback works when reading the attribute but not in queries.

TranslatedVirtualField.__get__() already skips an empty translation and continues down the fallback chain (test_fallback_getting_CharField covers that). as_expression() builds a COALESCE, which only skips NULL, so values(), filter() and order_by() hand back the empty string instead of the fallback value.

I wrapped every i18n lookup in the coalesce chain in NULLIF(<lookup>, ''), so an empty translation is treated as missing there too. The lookup for the default language points at the original field and is the last resort of the chain, so I left it as it is; that keeps the current result when every value is empty.

Added FallbackEmptyStringTest in tests/test_querysets.py, covering values_list(), filter() and a model using fallback_language_field.

Fixes #139

@shreyanshj10
shreyanshj10 marked this pull request as ready for review September 29, 2026 13:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Fallback for empty string

1 participant