Skip to content

feat(i18n): show spatial coverage in pt - #1669

Open
rdahis wants to merge 1 commit into
mainfrom
feat/spatial-coverage-pt
Open

feat(i18n): show spatial coverage in pt#1669
rdahis wants to merge 1 commit into
mainfrom
feat/spatial-coverage-pt

Conversation

@rdahis

@rdahis rdahis commented Sep 4, 2026

Copy link
Copy Markdown
Member

Summary

The spatial coverage field was gated behind hardcoded locale !== 'pt' checks, so it rendered only on the en and es pages. This removes those gates.

The pt data was never missing. The backend has always exposed spatialCoverageNamePt on both DatasetNode and TableNode, and /search/?locale=pt returns pt names in both results and aggregations — the gates were hiding data that was already there.

Changes

File Change
pages/dataset/[dataset].js Drop the pt gate on the spatial coverage grid item
components/organisms/DatasetSearchCard.js Drop the pt gate on the metadata row; fix card height at 165px (it was shortened to 138px only for pt)
pages/search.js Drop the pt gate on the spatial coverage filter accordion
components/organisms/TablePage.js Re-enable the block, which was commented out for every locale
pages/api/tables/getTable.js Add spatialCoverageName${locale} to the table query

Note on the table page

The table block was commented out for all locales, not just pt. Re-enabling it alone would have rendered "Não informado" everywhere, because the table GraphQL query never fetched the field — so spatialCoverageName${capitalize(locale)} is now added to getTable.js.

Translations for spatialCoverage, table.spatialCoverage and table.notProvided already existed in all three locale files; no locale JSON changes were needed.

Test plan

  • next build passes (exit 0), statically generating 1200+ /pt/dataset/* pages
  • All five changed files parse cleanly
  • Verified against the production backend that spatialCoverageNamePt resolves on DatasetNode and TableNode, and that the new table query is valid for Pt/En/Es
  • Verified /search/?locale=pt returns pt spatial_coverage on results and pt names in the spatial_coverages aggregation
  • Manual pass over /pt/dataset/<id>, its table tab, and /pt/search to confirm the field and filter render

Git Flow note

Per CLAUDE.md this branch is cut off main. The companion PR into staging is not opened yet: origin/staging is currently missing 13 commits that are on main, so merging this branch there now would drag those along. Better to open it after the next staging reset.

The spatial coverage field was gated behind `locale !== 'pt'`, so it
rendered only on the en and es pages. The backend has always exposed
`spatialCoverageNamePt` on both DatasetNode and TableNode, and the
`/search/` endpoint returns pt names in both results and aggregations,
so the gates were hiding data that was already there.

- dataset page: drop the pt gate on the spatial coverage grid item
- search result card: drop the pt gate on the metadata row, and fix
  the card height at 165px (it was shortened to 138px only for pt)
- search sidebar: drop the pt gate on the spatial coverage filter
- table page: re-enable the block, which was commented out for every
  locale, and add `spatialCoverageName${locale}` to the table query,
  which never fetched it

pt/en/es translations for `spatialCoverage`, `table.spatialCoverage`
and `table.notProvided` already existed in all three locale files.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@rdahis rdahis self-assigned this Sep 4, 2026
@rdahis rdahis added this to Website-UX Sep 4, 2026
@rdahis rdahis moved this to Em andamento in Website-UX Sep 4, 2026
@rdahis

rdahis commented Sep 4, 2026

Copy link
Copy Markdown
Member Author

Com o crescimento do número de conjuntos de outros países, está na hora de exibirmos a cobertura espacial de cada um também no website em português.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Em andamento

Development

Successfully merging this pull request may close these issues.

1 participant