allow unicode characters in filenames

[gumaerc]

What are the relevant tickets?

Closes https://github.com/mitodl/ocw-studio/issues/2084

Description (What does it do?)

This PR alters calls to django.utils.text.slugify and sets allow_unicode=True. The default is False, and since we don't explicitly set it to True, we end up with blank file names in scenarios such as syncing a gdrive file with a unicode filename or creating WebsiteContent with a unicode title.

Screenshots (if appropriate):

How can this be tested?

• Spin up ocw-studio on this branch and ensure you are set up for publishing sites locally
• Open any existing site that uses the ocw-course starter or create a new one, and if you create a new site make sure you visit the Metadata section and fill out the minimum required metadata for the site to publish
• Go to the Pages section and create a page using the title "テスト ページ" using any description or content you want
• Save the page and go to the Menu section
• Add an internal menu entry pointing to the page we just created
• Publish the site to draft
• Wait for the site to publish, then browse to it using the link in the publish drawer
• Click on the menu item we created and assure that the link points to the page we created, properly using the unicode characters in the slug

[pdpinch]

What slug/URL do we get when the title is set to テスト ページ ?

[HussainTaj-arbisoft]

Perhaps we should make only the filenames Unicode compatible and leave all other fields incompatible for now. Though, this distinction will be psychological because users can still enter unicode characters in some fields and we'll just strip them.

[gumaerc]

What slug/URL do we get when the title is set to テスト ページ ?

@pdpinch We would get a slug of テスト-ページ, which modern browsers do support but older operating systems / browsers may have issues with this. @HussainTaj-arbisoft has highlighted a number of areas where Unicode characters will be problematic, and I'm going to step back the scope of this PR to take that into account, although I didn't get a chance to address this today.

[gumaerc]

@HussainTaj-arbisoft This is ready for another look. I narrowed the scope so only files uploaded thru Google Drive and files created by creating WebsiteContent objects are affected. With Google Drive files, Django automatically URL encodes the file.url property, which is why you were seeing the encoded value in the frontend. I simply modified the Javascript to decode the value before displaying it, which should be fine since that's only for display, not editing. When the URL is injected into markdown, it will still be URL encoded. This will give us the greatest compatibility, and when the user downloads the file it should have the original utf-8 based filename if their browser supports decoding it.