Repository navigation
feat(i18n): show spatial coverage fields - #1669
Merged
Merged
Conversation
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>
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. |
The two blocks were stacked, so the spatial list sat under a mostly-empty line left by the temporal bar. They now share a row from `lg` up and stack again on narrow viewports. The temporal bar is a fixed-width visual, so it keeps `fit-content` and the spatial list takes the rest of the row. The per-block `marginBottom: 40px` moves to the wrapper, otherwise the row would carry it twice. next build passes, statically generating 1,364 pages.
Member
Author
|
Seria bom subir esse PR logo. @AldemirLucas conseguiu revisar? |
rdahis
changed the title
This branch was successfully deployed
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.
Summary
The spatial coverage field was gated behind hardcoded
locale !== 'pt'checks, so it rendered only on theenandespages. This removes those gates.The
ptdata was never missing. The backend has always exposedspatialCoverageNamePton bothDatasetNodeandTableNode, and/search/?locale=ptreturns pt names in both results and aggregations — the gates were hiding data that was already there.Changes
pages/dataset/[dataset].jscomponents/organisms/DatasetSearchCard.js165px(it was shortened to138pxonly for pt)pages/search.jscomponents/organisms/TablePage.jspages/api/tables/getTable.jsspatialCoverageName${locale}to the table queryNote 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 togetTable.js.Translations for
spatialCoverage,table.spatialCoverageandtable.notProvidedalready existed in all three locale files; no locale JSON changes were needed.Test plan
next buildpasses (exit 0), statically generating 1200+/pt/dataset/*pagesspatialCoverageNamePtresolves onDatasetNodeandTableNode, and that the new table query is valid forPt/En/Es/search/?locale=ptreturns ptspatial_coverageon results and pt names in thespatial_coveragesaggregation/pt/dataset/<id>, its table tab, and/pt/searchto confirm the field and filter renderGit Flow note
Per
CLAUDE.mdthis branch is cut offmain. The companion PR intostagingis not opened yet:origin/stagingis currently missing 13 commits that are onmain, so merging this branch there now would drag those along. Better to open it after the nextstagingreset.