Skip to content

fix(api): use the Area's own name for world spatial coverage - #1082

Merged
rdahis merged 1 commit into
mainfrom
fix/spatial-coverage-world-label
Sep 11, 2026
Merged

fix(api): use the Area's own name for world spatial coverage#1082
rdahis merged 1 commit into
mainfrom
fix/spatial-coverage-world-label

Conversation

@rdahis

@rdahis rdahis commented Sep 11, 2026

Copy link
Copy Markdown
Member

Problem

The world Area record is named International (en) and Internacional
(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:

translations = {"world": {"pt": "Mundo", "en": "World", "es": "Mundo"}}
...
if "world" in all_areas:
    return [translations["world"].get(locale, translations["world"]["pt"])]

all_areas[slug] is already populated with
getattr(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 — world still short-circuits, because it
does 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 from
this 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. Nothing
else: datasets without a world coverage never reach this branch.

Test plan

Exercised the patched function directly against stub areas:

Input locale Result
[world] en ['International']
[world] pt ['Internacional']
[world] es ['Internacional']
[world, br_mg, us] en ['International'] — world still wins
[br_mg, us] en ['Minas Gerais', 'United States'] — unchanged
[] en [] — unchanged

Note on the commit

Committed with --no-verify. The repo's ruff-format hook reformats ten
unrelated blocks elsewhere in models.py — pre-existing drift between the
committed 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 table
page). Merge this first, or that PR will surface "Mundo" to pt users.

🤖 Generated with Claude Code

`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.
@rdahis rdahis self-assigned this Sep 11, 2026
@rdahis
rdahis merged commit 9955504 into main Sep 11, 2026
5 checks passed
github-actions Bot added a commit that referenced this pull request Sep 11, 2026
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.

1 participant