Implements check to prevent channel having different language from its content

[akolson]

Summary

Description of the change(s) you made

This fix ensures that a channel being published has the same language as at least one of the its content. The check is made by providing a dropdown with languages that are present within the channels content. The dropdown is only visible when;

1. A channel has a language different from its content
2. A channel is cheffed or private and is a first time publish.

Manual verification steps performed

1. Create a channel.
2. Add content to the channel, some with no languages, others with languages different from that set in the channel
3. Try to publish the created channel to see if the publish modal appears with a language dropdown. The dropdown should contain all languages you specified in the channels content.
4. Proceed to select the preferred language and publish
5. Change the channel language to any of the languages you specified earlier and proceed as described above. The language dropdown should not appear in this case.
6. Try also try out the process with a cheffed channel that hasn't been published yet.

Screenshots (if applicable)

Sample UI with dropdown

Does this introduce any tech-debt items?

---

Reviewer guidance

How can a reviewer test these changes?

• See manual verification steps

Are there any risky areas that deserve extra testing?

• Publishing a channel

References

Fixes #3902

Comments

---

Contributor's Checklist

PR process:

• If this is an important user-facing change, PR or related issue the CHANGELOG label been added to this PR. Note: items with this label will be added to the CHANGELOG at a later time
• If this includes an internal dependency change, a link to the diff is provided
• The docs label has been added if this introduces a change that needs to be updated in the user docs?
• If any Python requirements have changed, the updated requirements.txt files also included in this PR
• Opportunities for using Google Analytics here are noted
• Migrations are safe for a large db

Studio-specifc:

• All user-facing strings are translated properly
• The notranslate class been added to elements that shouldn't be translated by Google Chrome's automatic translation feature (e.g. icons, user-generated text)
• All UI components are LTR and RTL compliant
• Views are organized into pages, components, and layouts directories as described in the docs
• Users' storage used is recalculated properly on any changes to main tree files
• If there new ways this uses user data that needs to be factored into our Privacy Policy, it has been noted.

Testing:

• Code is clean and well-commented
• Contributor has fully tested the PR manually
• If there are any front-end changes, before/after screenshots are included
• Critical user journeys are covered by Gherkin stories
• Any new interactions have been added to the QA Sheet
• Critical and brittle code paths are covered by unit tests

---

Reviewer's Checklist

This section is for reviewers to fill out.

• Automated test coverage is satisfactory
• PR is fully functional
• PR has been tested for accessibility regressions
• External dependency files were updated if necessary (yarn and pip)
• Documentation is updated
• Contributor is in AUTHORS.md

[akolson]

@marcellamaki a heads up on the strings added

[akolson]

@marcellamaki a heads up on the strings added

[marcellamaki]

Hi @akolson I've done a code read through and manual QA, and I believe this is working as expected. I'll review the strings with Radina, as we may want to make some adjustments, but we can even do that after merge. I also want to do a final manual QA with a cheffed channel, which I haven't done yet (I expect it should still work! But I want to be thorough).

In the meantime though, the blocker here is for some reason I am seeing a more squished modal than you. I am not sure why it looks so different than your screenshot! I tried in both chrome and firefox and saw this in both browsers.

[akolson]

Thanks @marcellamaki for the review. Strange -- I'll check again.

[akolson]

@marcellamaki , for some reason i'm still not able to reproduce this, so I am probably missing some context

Chrome;

Brave;

Safari 😄

[marcellamaki]

Hmmmm well that is certainly interesting 😄 let me investigate further and revert back to you

[nucleogenesis]

@akolson @marcellamaki I tried to replicate the error above but couldn't on Firefox or Chromium (Linux).

I did notice that the dropdown is cut off by an overflow:hidden when I open it though.

[akolson]

@nucleogenesis yes, this one troubled me and didn't find an appropriate fix! Any ideas on how I can fix it?

[marcellamaki]

I suspect this is connected to previous issues of KModals and things popping out of their parent container (or not popping out, rather) . Not sure if anything mentioned in these past fixes is helpful, Samson. If there's something useful here and there's a relatively quick fix, we can include that. Otherwise, it's okay with me to do this in follow up, as it's not in the publish modal every time but rather an edge case (and it still works).

[akolson]

@marcellamaki, it seems like KDS v4 doesn't have the fix to the KModal + KSelect issue. And it also looks like KSelect was refactored recently so not sure if the fix was lost in the process?

[akolson]

I reopened learningequality/kolibri-design-system#324 so we can prioritize it in upcoming KDS releases

[marcellamaki]

thanks @akolson -- let's go ahead and get this merged into unstable, so we will have both the fix and the new strings in. If anything comes up in the QA team's testing similar to what I've seen, we can always open a follow up issue.

[radinamatic]

Technically, on my side the manual QA confirms the fix (I was not able to test with a cheffed channel that hasn't been published yet), but I'm getting the same badly sized modal as @marcellamaki on both Firefox and Chrome on Windows 10.

publish-languages.mp4

[akolson]

I suspect that this issue might be related to learningequality/kolibri-design-system#324

[akolson]

It looks like the fix is working but in the wrong way! Not sure why its not working on some systems like Jacob's and mine

[akolson]

I was able to replicate the issue in my local. The bug is as a result of the height calculation of the modal that seems to be a little off and thus the overlap. This will need to be fixed in KDS or furthermore the implementation overhauled using teleportation. For now, we'll set a manual height for the modal body to compensate for the inconsistency and that should fix the issue. cc @marcellamaki

[marcellamaki]

thank you @akolson! I think that will be a good option for this release.