OOB translations in admin UI

[jpople]

Closes PROD-1801

Description Of Changes

When adding a new translation to an existing experience config or privacy notice that matches a template, out-of-the-box translations are now supplied to the user when available and treated as the default for the privacy notice and experience translation forms.

Code Changes

• Query /available-translations endpoints
• Add state handling to privacy experience config and privacy notice forms to track whether a translation is a provided translation or one the user created
• Tweaked behavior of "unsaved changes" modal on experience translation form
• Add a default value for "'Acknowledge' button label" on experience translation form to fix bug with "Save" button being unexpectedly disabled
• Minor code cleanups around experience and notice forms

Steps to Confirm

The endpoints require the experience or notice to be based on a template, and in the test environment (at least for me) they're all pre-stocked with the OOB translations, but you can get equivalent behavior by just deleting a translation and then re-adding it.

Running fidesplus backend with the following in .fides/fides.toml:

[consent]
enable_oob_translations = true
enable_translations = true

Navigate to /consent/privacy-experience:

• Go to a provided OOB experience
• Delete a provided translation
• Re-add the translation for the language you just deleted
• Form should be pre-populated with OOB translation text, info box should show at top of form notifying that translation is default
• On clicking "back" or "cancel", modal should be shown asking if you want to discard the translation
• Should be able to save default translation as-is or make changes and then save
• After saving, re-open the translation you just saved
• No "default translation" notice should show
• Save button should be disabled until changes are made
• Return to main experience table, create a new experience config
• Fill out form with experience type and add privacy notices
• Add a translation
• Form should not be pre-populated

Navigate to /consent/privacy-notice:

• Go to a provided OOB notice
• Delete a provided translation
• Re-add the translation for the language you just deleted
• Title and description should be pre-populated with OOB translation text, info box should show at top of form
• Return to main privacy notice table, create a new privacy notice
• Add a translation
• Form should not be pre-populated

Pre-Merge Checklist

• All CI Pipelines Succeeded
• Issue Requirements are Met
• Relevant Follow-Up Issues Created
• Update CHANGELOG.md

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
fides-plus-nightly	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 15, 2024 9:58pm

[cypress]

Passing run #6736 ↗︎

0	4	0	0	0
⚠️ You've recorded test results over your free plan limit. Upgrade your plan to view test results.

Details:

Merge 7bb535b into 04b185b...
Project: fides	Commit: d4fe2d3d54 ℹ️
Status: Passed	Duration: 00:34 💡
Started: Mar 15, 2024 10:07 PM	Ended: Mar 15, 2024 10:08 PM

Review all test suite changes for PR #4718 ↗︎

[NevilleS]

Couple comments, but not a full review since I had to run!

[NevilleS]

Can you put the translationIsOOB into the same state for setTranslateToEdit(...) to me...? This feels like tricky state to manage independently.

[jpople]

@NevilleS That was the original approach that I tried taking, where I modified the type of translationToEdit to bundle an isOOB bool with the translation, but it ended up causing some headaches.

We want to only consider an OOB translation to be an OOB translation (for the purposes of submit behavior and showing the notice) when it's being created for the first time. So when we're setting translationToEdit, we need to be able to tell whether we're creating a new translation and populating with OOB values or editing a saved translation that happens to have all the same values as an OOB translation.

This means we'd need to be able to pass that isOOB value on creating a new translation, which is where the main problem is: handleCreateNewTranslation is ultimately called from the translations' ScrollableList component, which is typed to expect specifically an ExperienceTranslation and won't like extra fields. It would have required a lot of modifications to the ScrollableList to allow it to handle other types and conditionally pass optional properties, so it was much cleaner to implement this way.

Maybe a better variable name would help here to communicate that this state isn't really a property of the translation itself, but rather of what the user is currently doing. Do you think something like isUsingOOBValues would be better?

[Kelsey-Ethyca]

yes that rename makes sense to me

[NevilleS]

note: if you include the "isOOB" state in the translation object, this'll be easier to manage 😄

[Kelsey-Ethyca]

UAT ✅

1. ✅ When a customer who was migrated from consent v1 to multi-lang consent, when they add a new language, pre-populate the form with the OOB translations for the experience.
2. ✅ Provide a UI notification/indication to the user that the translations may not match their English translations, and that they should have a native speaker review. This will only show when the OOB is initially provided.

[Kelsey-Ethyca]

The rename is a nice to have. Please add a followup jira ticket to add tests!