Closed sebastianbarry closed 5 months ago
@shankari @Abby-Wheelis I created an issue for my comments!
The other consideration I wanted to make sure - If someone fills out the form and they (1) include another language in the translations section, and (2) choose default demographics option, then will the labelTemplate
field include the "Answered" translation for that language?
"survey_info": {
"surveys": {
"UserProfileSurvey": {
"formPath": "json/demo-survey-v2.json",
"version": 1,
"compatibleWith": 1,
"dataKey": "manual/demographic_survey",
"labelTemplate": {
"en": "Answered",
"es": "Contestada"
}
}
},
It wasn't a problem on this issue but I just noticed this field as I was going through this PR #64
For the first problem you're having, it looks like in your issues that you did not select a second language in the dropdown, so both the "english" and the "spanish" sections say that they are EN -- we allow people to specify the language code, could you try editing the comment in the auto-generated issue to so it says 'es' under the heading "second language"
This might raise a broader question of if we should change the defaults...
For the second issue, that is going to be a problem - there's a place for people to input the translations in the languages, following a format, but I have managed to hardcode that those translations get slotted in as 'en' and 'es' no matter what the languages are, great catch, thank you! We'll have to re-work the way we handle that in the parsing and probably make those fields required since we need them no matter if it's the default or a custom survey.
@Abby-Wheelis @sebastianbarry I am not sure that we need to support languages beyond en
and es
in the config. If we have other languages (such as lo
), we will need to translate all of the text in the app anyway, and we can just modify the config manually. If we can get this to work reliably for the common US case (en
and es
only), I think it is a win for now. Once we integrate the app text translation with locize and allow participants to potentially provide us automated translations, we can revisit that decision.
@shankari should I hardcode the two languages as en
and es
, then? Right now you could technically specify any two langauges from en
, es
, and lo
if you wanted to. Or, should we just know that anything other than the common US case of en
and es
is going to take more manual review and editing?
@Abby-Wheelis I think we should hardcode en
and es
and get this rolling for now. We can then design new languages more carefully in a future round.
@shankari @Abby-Wheelis
Since the first issue I was having was my user error, and the second issue we decided to go with hardcoded values, then this issue is good to close.
I filed a new Issue Form (https://github.com/e-mission/nrel-openpath-deploy-configs/issues/66) and automatic PR (https://github.com/e-mission/nrel-openpath-deploy-configs/pull/67)
The automated config that was created (https://github.com/e-mission/nrel-openpath-deploy-configs/pull/64) from the issue form I filled out (https://github.com/e-mission/nrel-openpath-deploy-configs/issues/63) filled in the
intro > translated text > en
field with thees
translations I put in. I filled in both sections for EN and ES in the issue form, but it only created onetranslated text
field,en
, and put the EN translations into it.