Multilingual support for notifications and system messages

[StefanMunnes]

Description

For all people who create non-English surveys, such as myself with mainly German surveys, I would find it useful to have a multilingual option for the standard text output.

As far as I can see, this concerns the warning messages for required questions, the final page, survey rating, redirect and the standard values for next and exit survey buttons. There are also validation output for function arguments (e.g. sd_output(type)).
I'm not talking about error messages in general or the admin page, just what the survey participants might see.

To achieve this, I would have an additional config YAML/JSON or R file that hast all provided translations and the option in the yaml-header in the survey.qmd file to choose the correct language. One could also think about the possibility for the user, to provide an additional config file in their project folder, if the needed language is not available from default.

translations.yml

en:
  next_button: "Next"
  exit_survey:  "Are you sure you want to exit the survey?"
  required_response: "Please answer all required questions before proceeding."
de:
  next_button: "Weiter"
  exit_survey: "Sind Sie sicher, dass Sie die Umfrage verlassen möchten?"
  required_response: "Bitte beantworten Sie alle Pflichtfragen, bevor Sie fortfahren."

survey.qmd

---
format: html
echo: false
warning: false
language: "de" # or "fr", etc.
---

If you like this idea, I'm willing to prepare a PR.

[jhelvy]

This is a good idea! I like this architecture, though I might suggest making it an option in sd_server() rather than the survey.qmd yaml header. If you had something like sd_server(language = 'de'), it would be more straightfoward to work with as these notifications all occur from inside the sd_server() function (I think). You could read in the translations.yml file then just extract the appropriate language based on whatever was provided for the language argument.

The only one that I think will be different is the next buttons, because the button labels are created using the sd_next() button, which is defined in the survey.qmd file. But you can always provide a custom label directly inside the survey.qmd file, e.g. sd_next(label = 'Weiter'). Of course, that is kind of tedious, so you could also make an edit to run_config() to swap out the default next button text with language from the translations.yml file.

A quick word about any PRs you might send soon - we're in the process of getting things on CRAN as a v0.4.0, so that will be our immediate priority. You might want to change until we get it there in case we have to change things based on feedback from CRAN.

[StefanMunnes]

That's great news, wish you good luck with CRAN!

I see when I have time to implement and will provide a PR soon. But I'm willing to rework on this if there are some changes needed due to the CRAN suggestions.

[jhelvy]

This is now supported with PR #138 thanks to @StefanMunnes! Really nice feature addition. This allows system messages and date formats to be specified by a language using the language argument in sd_server(). Custom language messages can be further modified by providing a translations.yml file in the root project folder. Also, we added new sd_create_translations() function to generate a template translations.yml file to use to edit the system messages.

[jhelvy]

@pingfan-hu just found some small issues in the translations, so let's wait until he sorts them out. He's also building out a feature to support cookies so that the user's session will be restored if they refresh the page. So I would suggest waiting a bit anyway until we get that sorted out. We're aiming to make that v0.5.0, then we'll get that on CRAN.

The main challenge I think with importing questions from a questions.yml file is that we'll still need to generate the html for the question, so it's not as simple as just reading in the metadata. I think we'll have to do something like create a temporary qmd file that we render and then parse out the rendered html. That of course would only need to be done once, after which the content will be stored in the pages.rds file.

[StefanMunnes]

Oh no, issues don't sound good. Hopefully they can be solved without too much effort. I also saw the commit with the bug is_matrix and I am glad that you are so careful.

My idea for the import is that there is a check in the sd_question() function, which, if only the ID is defined (no type and no label), takes the respective values from the question object loaded and prepared in the config, which are then made available in the function. As with the get_translations() functions in ui.R. But yes, I will wait and try carefully to see how this can be achieved.

[jhelvy]

Only a small issue, he's found a solution though. It was only if the user rendered the survey.qmd directly instead of running the app.R file. If you rendered the qmd it would error on some of the ui functions because the language settings weren't established yet. It will now just default to English if someone does that just so that it will render without error. It won't matter though because the file will be overwritten with the appropriate language when they run the app.R file anyway. I just expect that some people will probably render the qmd first without knowing that it will get overwritten.

And yes, I think your idea of how to handle the questions.yml file should work. The sd_question() function should be able to take only an id argument, in which case it will then look for a questions.yml file in the root directory and can populate the rest of the function arguments from the values stored in the questions.yml file that matches with the id. So I think it's really just an update to how sd_question() works. After it runs once, all that content will be stored in the pages.rds.

[pingfan-hu]

Hi @StefanMunnes ! I located the issue and am merging your updates with my cookies improvement. I'll be able to finish editing, bump our version to 0.5, and push to main. I'll let you know when it's done.

[pingfan-hu]

Now v0.5 is published!