While the sentence ends up being ultimately handled by the <DynamicSentence /> component which will use the translateText (utils/lang) to interpolate sentence and params, in this case the params themselves will often be English text that is not translated, resulting in a translated string with untranslated parameters.
This PR adds a utils/geodescriber utility to handle sentences and params, sending the parameters for translation with Transifex using the existing translateText utility, before passing the sentence to be ultimately handled by <DynamicSentence />.
Because there was already an exception for the area_0 parameter, which seems to always be an area (and regex was being used to add a space between value and unit in order to keep the display consistent with the rest of the app), the utility also handles this.
Duplicated code (because both AOI title and description need to be handled), originally in the providers/geodescriber-provider/selectors.js, was pulled into the utility as well, to ensure consistency and make it easier to tweak this in the future.
This solution is not meant to be an end-all code refactor, its goal is to allow those parameters coming from the endpoint to be translated, while keeping things simple and the least prone to bugs as possible.
Notes
The sentences structure returned by the endpoint differ slightly from one another, as thus, some AOIs will have fully untranslated sentences, as they are not yet set up on Transifex.
This implementation doesn't automagically solve FLAG-1125, as it looks like the sentences are actually not translated in Transifex (some are, others aren't. There are many slightly different ones coming from the external endpoint). However, it does aim to solve the untranslated parameters coming from that very same API.
Testing
I'm not sure proper testing can be done in advance, not until parameters are translated in Transifex (to which I don't have access). The way I tested (locally) that transifex is seeing the new params setup was as such:
Visited the AOI above locally
In utils/geodescriber.js, translateSentenceParams:
I've added params['lsf_1'] = 'Area of interest'
_lsf_1 corresponds to "marine area" in the parameters, and we know that "Area of interest" is a string that exists translated in Transifex_
Verified that when switching languages, the (mocked) parameter was being translated
Overview
When visualizing an AOI (be it on the map or dashboard), the sentence is provided by the https://api.resourcewatch.org/geodescriber/geom/ endpoint, alongside parameters for interpolation.
While the sentence ends up being ultimately handled by the
<DynamicSentence />component which will use thetranslateText(utils/lang) to interpolatesentenceandparams, in this case theparamsthemselves will often be English text that is not translated, resulting in a translated string with untranslated parameters.This PR adds a
utils/geodescriberutility to handlesentences andparams, sending the parameters for translation with Transifex using the existingtranslateTextutility, before passing the sentence to be ultimately handled by<DynamicSentence />.Because there was already an exception for the
area_0parameter, which seems to always be an area (and regex was being used to add a space between value and unit in order to keep the display consistent with the rest of the app), the utility also handles this.Duplicated code (because both AOI title and description need to be handled), originally in the
providers/geodescriber-provider/selectors.js, was pulled into the utility as well, to ensure consistency and make it easier to tweak this in the future.This solution is not meant to be an end-all code refactor, its goal is to allow those parameters coming from the endpoint to be translated, while keeping things simple and the least prone to bugs as possible.
Notes
The sentences structure returned by the endpoint differ slightly from one another, as thus, some AOIs will have fully untranslated sentences, as they are not yet set up on Transifex.
An example with an AOI with a translated base sentence: https://gfw-staging-pr-4835.herokuapp.com/dashboards/aoi/65bd49398f6a2e001be90ec9/
This implementation doesn't automagically solve FLAG-1125, as it looks like the sentences are actually not translated in Transifex (some are, others aren't. There are many slightly different ones coming from the external endpoint). However, it does aim to solve the untranslated parameters coming from that very same API.
Testing
I'm not sure proper testing can be done in advance, not until parameters are translated in Transifex (to which I don't have access). The way I tested (locally) that transifex is seeing the new params setup was as such:
utils/geodescriber.js,translateSentenceParams:params['lsf_1'] = 'Area of interest'_
lsf_1corresponds to "marine area" in the parameters, and we know that "Area of interest" is a string that exists translated in Transifex_Tracking
FLAG-1125