Unable to Access Workspace when Creating a Workspace with non-English Language

[devleejb]

What happened: When creating a Workspace using a non-English language, specifically when using characters outside the English alphabet, the user is unable to access the Workspace. The slug creation process seems to be encountering issues when handling non-English characters.

What you expected to happen: I expected to be able to create a Workspace using a non-English language and access it without any issues.

How to reproduce it (as minimally and precisely as possible):

1. Create a new Workspace.
2. Use non-English characters (such as Korean, Chinese, etc.) during the Workspace creation process.
3. Try to access the created Workspace.

Anything else we need to know?: It is important to ensure that the slug creation process can handle non-English characters to allow users to create Workspaces in different languages.

Environment:

• Operating system: ALL
• Browser and version: ALL
• CodePair version: ALL

[minai621]

This issue seems to be related to #234 . Can I try this issue?

[devleejb]

@minai621 Sure! It would be good to leave comments on the plan before implementation.

[minai621]

@devleejb The root cause of the issue is that a blank string is returned because slugify does not support Korean. slugify has no attempt to support Koren in locale. locales.json Therefore, the solution is to use a library that romanizes multilingualism. Among the libraries that support es6, chose transliteration, a library that seamlessly supports multilingualism.

[minai621]

@devleejb I tried using transliteration. but, it can't support to all languages. And we have to consider all the texts as well as the language. For example, an emoji is ignored in the process of slug conversion in transliteration. How about using Unicode, or Hash? However, the currently created workspace needs to be converted into Unicode and Hash.

[injae-kim]

we have to consider all the texts as well as the language. How about using Unicode, or Hash?

• medium(encoding + hash): https://medium.com/opensource-contributors/%EB%AA%A8%EC%A7%91%EC%A4%91-%EC%98%A4%ED%94%88%EC%86%8C%EC%8A%A4-%EB%A9%98%ED%86%A0%EB%A7%81-%EB%AA%A8%EA%B0%81%EC%BD%94-5%EA%B8%B0-at-%EA%B0%95%EB%82%A8-%EC%B0%B8%EC%97%AC%EC%9E%90%EB%A5%BC-%EB%AA%A8%EC%A7%91%ED%95%A9%EB%8B%88%EB%8B%A4-403d7f9ff789
  • only hash works well too, https://medium.com/opensource-contributors/403d7f9ff789
• velog(encoding): https://velog.io/@osohyun0224/%EB%82%98%EC%9D%98-%EC%B2%AB-%EC%98%A4%ED%94%88%EC%86%8C%EC%8A%A4-%EA%B8%B0%EC%97%AC-%EB%8F%84%EC%A0%84%ED%95%98%EA%B8%B0-Playwright

+1, encoding + hash url slug is widely used like above 👍

[devleejb]

@injae-kim Thank you for your suggestion!

I'd like to introduce only encoding because of consistency. The introduction of Slug in CodePair was intended to quickly identify Workspaces through clean URLs (Like GitHub URL). Therefore, how about maintaining this by allowing non-English languages to be accessed through encoding, even though they may not be as clean?

[minai621]

@devleejb Returns an empty string if user has entered only an emoji. (ex: 😀😀😀 or unsupported languages..) If using slug, the input must be in English or contain at least two English characters.

[devleejb]

@minai621 I think only at least two letters is okay. We can encode letters except English. Is it right?

[minai621]

@devleejb

@minai621 I think only at least two letters is okay. We can encode letters except English. Is it right?

That's right. I think that's best to do it, so I made a this pull request. #261