Improve product handle auto-generation from product title for non-latin scripts

[supernes]

Medusa 2 has a feature which automatically generates handles (URL-safe ids) from product titles when one is not explicitly entered during product creation.

The way it does it however is very crude, stripping out non-alphanumeric characters instead of trying to transliterate them or map them to URL-valid strings. It's so aggressive that it doesn't even allow URL-encoded strings, which is the usual way of representing non-latin characters in URLs.

medusa/packages/core/utils/src/common/to-handle.ts

Lines 11 to 20 in d07f707

	export const toHandle = (value: string): string => {
	return kebabCase(
	value
	.toLowerCase()
	.normalize("NFD")
	.replace(/[\u0300-\u036f]/g, "")
	)
	.replace(/[^a-z0-9A-Z-]/g, "")
	.replace(/-{2,}/g, "-")
	}

> toHandle("Product title")
'product-title'
> toHandle("Име на продукт")
'-'

Expected acceptable results:

• 'ime-na-produkt'
• 'име-на-продукт'
• '%D0%98%D0%BC%D0%B5-%D0%BD%D0%B0-%D0%BF%D1%80%D0%BE%D0%B4%D1%83%D0%BA%D1%82'

This is a big UX problem for platforms whose primary locale is not US English because it renders the handle auto-generation useless. Admins adding or editing products have to manually type handles, which slows down product creation flow.

Please consider improving handle auto-generation by replacing the toHandle function with something that handles non-latin scripts (like slugify or similar).

[v0eak]

Not sure where toHandle is used internally, but I had a similar problem some time ago and proposed a merge, but it did not get any traction 🤷

9018

Maybe it might help you anyways

[supernes]

It's used only for product handles, so modifying it shouldn't impact any other functionality.
Product categories have handles too, but they're entirely optional and not auto-generated (don't use this logic).

When adding a prodcut, toHandle is called before isValidHandle (when a handle is not supplied), and the former will strip all non-latin characters even if the latter function would consider them valid.

I might try submitting a PR once I have time to test a proper fix as it seems like a straightforward change, but I'm still hoping the team can fix it sooner since they seem to be working on i18n ATM.