feat: add settings tab and toggle for multi lang feature

[siddarth2824]

Context

• Add settings tab and toggle to allow users to turn on the multi-language translation feature for their form.
• This PR is the second PR to introduce the settings tab and toggle view to allow users to turn on and off the multi-language translation feature.
• This PR does not introduce any changes to the public form and only introduces the functionality to turn on/off support for multi-language translation.

Changes

• Add views for settings tab and toggle.
• Add mutations to update the following form's setting field:
  • Set boolean value for hasMultiLang to indicate if a form supports the multiple languages
  • Set the languages, in supportedLanguages field, that the a form supports

Before & After Screenshots

Description	Before	After
Addition of settings tab on the side bar and toggle for turning on/off support for multi-language translation feature
Language support list when toggle is turned on and success toast
Toast when support for multi-translation is turned off
Tooltip when hovering over icon to able/disable language
Tooltip when hovering over icon to edit translation
Toast when disabling support for a specific language
Toast when enabling support for a specific language

Tests

TC 1: Turning on toggle adds support for default supported languages and sets the hasMultiLang attribute to be true

1. Turn on the toggle and check the forms table to verify that the supportedLanguages field is populated with the default supported languages ([en-SG, zh-SG, ms-SG, ta-SG]) and the hasMultiLang value is true

TC 2: Disable and then enable support for a specific language

1. Turn on toggle to add support for the multi-language translation feature
2. Disable "Chinese"
3. Verify in the forms table for the particular form that the supportedLanguages field now contains [en-SG, ms-SG, ta-SG]
4. Then enable "Chinese" language
5. Verify in the forms table for the particular form that the supportedLanguages field now contains [en-SG, ms-SG, ta-SG]

[kevin9foong]

Suggestion: instead of using comments to describe what the code is doing, the code should probably be able to explain itself (i prefer reserving comments to describe why something is done)

The following code block (to line 76) could be replaced with something like this:

Suggested change

	// Remove support for this language if it exists in supportedLanguages
	const isLanguageSupportedPreviously = !!supportedLanguages.find(language)
	const isAddSupport = !isLanguageSupportedPreviously
	const updatedSupportedLanguages = isAddSupport
	? supportedLanguage.concat(language)
	: supportedLanguages.filter(l => l !== language)
	setIsLanguageSupported(isAddSupport)
	return mutateFormSupportedLanguages.mutate({
	nextSupportedLanguages: updatedSupportedLanguages,
	selectedLanguage: language,
	})

[kevin9foong]

formsg has a convention to use
{!!isLast ? <Divider /> : null} instead of using &&

[siddarth2824]

I understand. Just out of curiosity is there any reason why the convention is preferred over using &&?

[kevin9foong]

I'm not sure, I think it was a practice that has been applied before throughout the codebase (due to the belief that it is more readable) and hence just maintained for overall consistency in the codebase

[kevin9foong]

not sure but would this cause an inconsistency error if error occurs for this but previous mutation has succeeded?

[siddarth2824]

Thanks for bringing up this scenario. I changed the implementation to only add the array of supported languages in the first instance that the user turns on the toggle for this feature. I also updated the model to have a default false value for the hasMultiLang attribute. Hence now if the mutation to update the hasMultiLang attribute fail, the data is not in an inconsistent state because the intended implementation was to still keep the list of supported languages even if the hasMultiLang value has not been updated. This is to be able to retrieve back the list of supported languages when the user turns the toggle back on.

I hope this clarifies your question.

[kevin9foong]

hi @siddarth2824,

In order for us to ensure there are no regressions and everything is working as expected, could you add in the PR description the following:

• manual tests to run to ensure no regressions/feature works
• UT added to cover the new functionality
• some screenshots of before/after so others in the future know what this PR is about without executing the code locally.

This also helps me as a reviewer who may not have much context of this feature to avoid missing anything out

You may refer to the following PR as reference: PR 7566

[siddarth2824]

I have added the screenshots and manual tests that can be run to ensure the functionality works as it should as suggested. Do let me know if anything else is required from my side as I am still getting to used to the team's practices for making PRs. Thanks!

[kevin9foong]

Hi @siddarth2824, could we add some Chromatic Visual tests for the new settings page tab (& other UI components) as well?

the rationale is to provide UI snapshots and prevent future regressions

[kevin9foong]

Thanks for adding the chromatic tests!