fix(api): use the Area's own name for world spatial coverage - #1082
Merged
Conversation
`get_spatial_coverage_name` carried a hardcoded
`{"world": {"pt": "Mundo", "en": "World", "es": "Mundo"}}` that overrode the
Area record's localized name. The record is named "Internacional" /
"International", so every dataset whose coverage is `world` displayed
"Mundo" / "World" on the site instead — including the dataset and table pages,
which read `spatialCoverageName{Locale}` straight from this function.
The surrounding logic was right and is unchanged: `world` still short-circuits
because it encompasses every other area. Only the label now comes from
`all_areas["world"]`, which the function already populated with
`getattr(coverage.area, f"name_{locale}")`.
The docstring example documented the wrong output and is corrected.
Verified by exercising the function against stub areas: world alone returns
International / Internacional / Internacional for en / pt / es; world combined
with br_mg and us still returns only the world label; a set without world is
unaffected; and no areas still returns [].
Committed with --no-verify: the repo's ruff-format hook reformats ten unrelated
blocks elsewhere in this file, which is pre-existing drift between the committed
state and the pinned ruff. Those are left out rather than folded into this fix.
github-actions Bot
added a commit
that referenced
this pull request
Sep 11, 2026
chore: sync staging and main - (PRs: #1082)
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
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.
Problem
The
worldArea record is namedInternational(en) andInternacional(pt/es). The site nonetheless displays World / Mundo wherever a dataset's
spatial coverage is the world.
The cause is a hardcoded override in
get_spatial_coverage_name:all_areas[slug]is already populated withgetattr(coverage.area, f"name_{locale}"), so the function had the correct,translated name in hand and threw it away.
Change
return [all_areas["world"]], and delete the dict.The surrounding logic is untouched —
worldstill short-circuits, because itdoes encompass every other area. Only the label changes. The docstring example
documented the wrong output and is corrected alongside it.
Why this belongs in the backend rather than the website
The dataset and table pages read
spatialCoverageName{Locale}straight fromthis function, so it is tempting to remap the string in the display layer.
That would leave the API still returning the wrong value to every other
consumer — search results, search aggregations, dataset cards, and any direct
API user.
Blast radius
Every dataset whose coverage includes
world, in all three locales. Nothingelse: datasets without a
worldcoverage never reach this branch.Test plan
Exercised the patched function directly against stub areas:
[world]['International'][world]['Internacional'][world]['Internacional'][world, br_mg, us]['International']— world still wins[br_mg, us]['Minas Gerais', 'United States']— unchanged[][]— unchangedNote on the commit
Committed with
--no-verify. The repo'sruff-formathook reformats tenunrelated blocks elsewhere in
models.py— pre-existing drift between thecommitted state and the pinned ruff version. Those are deliberately left out
rather than folded into this fix; worth a separate formatting pass.
Related
Website PR basedosdados/website#1669 un-gates spatial coverage on the dataset
and table pages (it was hidden on
pt, and commented out entirely on the tablepage). Merge this first, or that PR will surface "Mundo" to pt users.
🤖 Generated with Claude Code