Closed brasfadmin closed 6 years ago
So I imagine this working like a list of keywords for each indicator. These could then be returned with the indicators.json
in an (optional) array for each indicator.
The current search requires a case-insensitive match, so in instances where an alternative search term is matched, that should be indicated to the user.
I estimate that the changes required on the code side should be approximately 3 hours. Ongoing development of the alternate terms can happen in parallel and in isolation to the code.
We could add it into the indicator metadata easily enough. A keywords
field, or similar. If we make sure it's an array then it'll parse really easily into the JS
Poss one for sprint 12 - to be discussed with SDGs team
Doug to add a keywords field. Comma separated list of fields. When I'm done I'll hand back to Shane to add more fields into the search: in particular indicator available.
@shaneporter is this easy to do in the JS or do we need a pre-processing tokeniser?
Should be easy to do in the JS, @dougmet.
page.data_keywords
now exists with an example in 3-a-1
. Over to you @shaneporter in branch e/2020
have alternate terms for technical terms in the search, so the public would more easily find the indicator. eg baby deaths does not bring up neonatal mortality. Another god example https://datasciencecampus.github.io/sdg-indicators/3-a-1/ - doesn't come up when search on 'smoking' as has word 'tobacco' in the title and not words like 'smoking'.